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METHOD OF DETERMINING VISIBILITY TO A REMOTE DATABASE 
CLIENT OF A PLURALITY OF DATABASE TRANSACTIONS HAVING 
VARIABLE VISIBILITY STRENGTHS 

5 

INTRODUCTTON 

L Technical Field 

This invention relates to a system and method for providing updates to a network of 
10 partially replicated relational database systems, and, more particularly, for providing 
an efficient means for computing the visibility to a client on the network of a 
transaction processed against the database. 

n. Background 

1 5 Relational databases are a commonly-employed data structure for representing 

data in a business or other environment. A relational database represents data in the 
form of a coUection of two-dimensional tables. Each table comprises a series of cells 
arranged in rows and columns. Typically, a row in a table represents a particular 
observation. A column represents either a data field or a pointer to a row in another 

20 table. 

For example, a database describing an organizational structure may have one 
table to describe each position in the organization, and another table to describe each 
employee in the organization. The employee table may include information specific 

25 to the employee, such as name, employee number, age, salary, etc. The position 
table may include information specific to the position, such as the position title 
("salesman", "vice president", etc.), a salary range, and the like. The tables may be 
related by, for example, providing in each row of the employee table a pointer to a 
particular row in the position table, coordinated so that, for each row in the employee 

30 table, there is a pointer to the particular row in the position table that describes that 
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employee's position. A relational database management system (EDBMS) supports 
"joining" these tables in response to a query from a user, so that the user making a 
query about, for example, a particular employee, may be provided with a report of 
the selected employee, including not only the information in the employee table, but 
5 also the mformation in the related position table. 

Relational databases may be much more complex than this example, with 
several tables and a multiplicity of relations among them. 

10 With the widespread use of inexpensive portable computers, it is advantageous 

to replicate a database onto a portable computer for reference at locations remote 
from the central computer. The replicated database may then be referenced by the 
user of the portable computer, without requiring reference to the main database, 
which may be maintained at a central location inconvenient to the user of the portable 

15 computer. However, there are a number of difficulties with the use of a replicated 
database. 

One disadvantage is that a full copy of the central database may require more 
data storage than is desired or economical. For example, a salesman woildng in the 

20 field may need to refer to the database for information regarding sales opportunities 
in his sales area, but have no need to refer to any information regarding sales 
opportunities outside of his area. One possible approach to reduce the amount of 
required data storage is to simply replicate only that portion of the database that is 
needed by the user. However, this approach does not recognize that the criteria to 

25 determine which portions of the data are required is likely to vary over time. For 
example, the salesman may have a new city added to his territory. Under 
conventional approaches, the salesman would need to re-replicate his local copy of 
the database, this tune selecting data mcluding the added city. Such a practice is 
inconvenient, subject to error, and time-consuming. 

30 

A further disadvantage to a reheated database is the dif^culties encountered 
in attempting to update data using the replicated copy. A change made to the 
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rqilicated database is not made to the central database, leading to a discrepancy 
between the information that is stored in the replicated copy of the database and the 
information that is stored in the central database. Although it is possible to journal 
modifications made to the replicated copy and apply an identical modification to the 
5 central database, one problem that this approach faces is the possibility of colliding 
updates; that is, where a user of a replicated copy makes a change to data that is also 
changed by a user of the central copy or by the user of another replicated copy. 

It is therefore desirable to provide a capability to maintain one or more 
10 partially-replicated copies of a central database, in such a way that the degree of 
replication may be easily changed without requiring a refresh of the entire replicated 
database, and that permits updates to be coordinated among users of the central 
database and users of the partially replicated databases. 

15 SUMMARY OF THE INVENTION 

The present invention is directed to a method of maintaining a partially 
replicated database in such a way that updates made to a central database, or to 
another partially replicated database, are selectively propagated to the partially 
replicated database. Updates are propagated to a partially replicated database if the 

20 owner of the partially replicated database is deemed to have visibility to the data 
being updated. Visibility is determined by use of predetermined rules stored in a 
rules database. In one aspect of the invention, the stored rules are assessed against 
data content of various tables that make up a logical entity, known as a docking 
object, that is being updated. 

25 

In another aspect of the invention, the stored rules are assessed against data 
content of one or more docking objects that are not necessarily updated, but that are 
related to a docking object being updated. In one embodiment, the visibility attributes 
of the related docking objects are recursively determined. 

30 

In yet another aspect of the invention, changes in visibility are determined to 
enable the central computer to direct the nodes to insert the docking object into its 
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paitially rq)licated database. Such changes in visibility aie determined so as to 
enable the central computer to direct a node to remove a docking object from its 
partially replicated database. 

5 In a further aspect of the invention, the predetermined rules are in declarative 

form and specify visibility of data based upon structure of the data without reference 
to data content. 

In still another aspect of the invention, the transactions made to the database 
10 are ordered and processed in such a way as to reduce the computational resources 
required to calculate the visibility of the transactions. 

In still another aspect of the invention, the transactions made to the database 
are ordered and processed using a cache in such a way as to reduce the computational 
15 resources required to calculate the visibility of the transactions. 

In still another aspect of the invention, database objects and transactions have 
an associated visibility strength used to determine the visibility of a transaction to an 
object. 

20 

In still another aspect of the invention, the visibility calculations are performed 
using a simplified set of rules located in a central dictionary. 

BRIEF DESCRIPTION OF THE DRAWINGS 
25 Figure 1 depicts an overview of the operation of one embodiment of the 

present invention. 

Figure 2 dq)icts a database schema that shows the relationship of the various 
components that make up a Docking Object. 

30 

Figure 3 depicts steps performed by an update manager to update a database. 
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Figure 4 depicts steps peifonned by a Docking Manager to transmit and/or 
receive one or more transaction logs. 

Figure 5 depicts the steps performed by a merge processor to merge 
S transaction log records into an existing database. 

Figure 6 dq)icts the steps performed by a log manager to prepare a partial 
transaction log. 

10 Figure 7 depicts the steps performed by a visibility calculator for calculating 

visibility for a docking object as invoked by a log manager. 

Figure 8 depicts the steps performed to synchronize a partially replicated 
database in response to a change in data visibility. 
IS Figure 9 depicts the structure of the database design of the transaction log 

table. 

Figure 10 depicts a database diagram for the central dictionary. 
DESCRIPTION OF SPECIFIC EMBODIMENTS 

20 Overview 

Figure 1 depicts an overview of the operation of one embodiment of the 
present invention. Figure 1 depicts a central computer system 1 and three remote 
computer systems (or "nodes") 21-a, 21-b, and 21-c. Each of nodes 21-a, 21-b and 
21-c are depicted in various states of communication with central computer system 
25 1, as will be more fiilly explained. Central computer system 1 includes a central 
database 3, a docking manager S, a merge processor 7 and a log manager 9. Central 
computer system 1 additionally optionally includes update manager 1 1 responsive to 
user input 13. 

30 Node 21-a is a remote computer system, such as a mobile client such as a 

laptop computer. Node 21-a includes a partially rqilicated remote database 23-a, 
update manager 31 -a responsive to user input 33-a, docking manager 25-a and merge 
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manager 27-a, In operation, update manager is responsive to user input 33-a to make 
changes to remote database 23-a as directed by the operator of node 21 -a. Updates 
made are recorded, or joumaled, in node update log 35-a. 

5 At some point at the convenience of the operator of node 21-a, node docking 

manager 35-a is activated, and enters into communication with central docking 
manager 5. Update log 35-a is taken as input by node docking manager 25-a, and 
provided to central docking manager 5. Central docking manager 5 creates a received 
node update log 19, which contains all the information that had been recorded in 

10 update log 35-a. Optionally, partial log 17-a is taken as input by central docking 
manager 5 and provided to node docking manager 25-a, as more fully described 
herein. 

At some point in time, at the convenience of the operator of central computer 
15 system 1 , merge processor 7 is activated. Merge processor 7 takes as input received 
node update log 19, and applies the updates described therein to central database 3. 
In the process of applying the updates from received node update log 19, merge 
processor journals the updates applied to central update log 15. Optionally, update 
manager 1 1 , responsive to user input 12 makes additional changed to central database 
20 3 as directed by the operator of central computer system 1 . The updates made by 
update manager 11 are additionally joumaled in central update log 15. 

At some point in time, at the convenience of the operator of central computer 
system 1, log manager 9 is activated. Log manager 9 takes as input central update 

25 log 15 and produces as output a set of partial logs 17-a, 17-b and 17-c according to 
visibility rules as will be fiirther described herein. Each of partial logs 17-a, 17-b 
and 17-c corresponds to one of nodes 21-a, 21-b and 21-c. When a node docking 
manager such as node docking manager 25-a enters into communication with central 
docking manager 5 and optionally requests transmission of its corresponding partial 

30 log, central docking manager 5 takes as input the appropriate partial log, such as 
partial log 17-a, and presents it to node docking manager 25-a. Node docking 
manager 25-a then replicates partial log 17-a as merge log 37-a. 
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At some point in the future, at the convenience of the operator of node 21-a, 
merge processor 27-a is activated. Merge processor 27-a takes as input merge log 
37-a, and applies the updates described therein to partially r^licated database 23-a. 

5 In addition to node 21-a, Figure 1 also depicts two additional nodes 21-b and 

21-c. Node 21-b is dq)icted in communication with central computer 1. However, 
unlike node 21-a, the operator of node 21-b has requested only to send his updates 
to central computer system 1 , and has not requested to be presented with changes 
made elsewhere to be made to his partially replicated database 23-b. This may be, 

10 for example, if the operator has an urgent update that must be made as soon as 
possible, but does not have the time to receive updates from other nodes. 
Accordingly, Figure 1 shows only transmission of node update log 35-a from node 
docking manager 25-b to central docking manager 5, and no transmission from central 
docking manager 5 to node docking manager 25-b. Accordingly, the merge manager 

15 for node 21-b is not activated and is not shown. 

Likewise, node 21-c is dqiicted as not in communication with central 
computer system 1 . Accordingly, the docking manager for node 21-c is not activated 
and is not shown. 

20 

By the cycle described above, updates made by each of nodes 21-a, 21-b and 
21-c are presented to central computer system 1, permitting central database 3 to be 
updated accordingly. In addition, each of the updates made by each of the nodes 21- 
a, 21-b and 21-c, as well as updates made on central computer system 1, are routed 
25 back to each of nodes 21-a, 21-b, and 21-c, thereby keeping each of partial databases 
23-a, 23-b and 23-c in synchronization with each other and with central database 3. 

Database Structure 

The synchronization of central database 3 with node databases 23-a, 23-b and 
30 23-c is performed using a construct called a Docking Object. A Docking Object 
consists of Member Tables (including one Primary Table), Visibility Rules, Visibility 
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Events, and related Docking Objects. Each docking object has a visibility level and 
visibility level attributer as will be described more fiilly herein below. 

A Member Table is a table of the relational database that makes up a docking 
5 object. When a docking object is propagated from central database 3 to one of node 
databases 23-a, 23-b or 23-c, the propagation takes the form of an insertion into each 
of the Member Tables associated with the particular docking object. Similarly, when 
a docking object is scheduled to be removed from a database, that removal consists 
of deleting records from the member tables associated with the docking object. For 
10 example, a docking object that represents a sales opportunity may include tables that 
represent the opportunity itself (e.g., named "S_OFrY"), the product whose sale is 
represented by the opportunity (e.g., named "S_OFrY_PROD"), the contact for the 
opportunity (e.g., named "S_OPTY_CONTACT"), etc. Each of these tables is said 
to be a member table of the "Opportunity Docking Object." In an additional aspect 
15 of hte invention, each member table row can have one or more rows that correspond 
to the docking object. 

A Primary Table is a Member Table that controls whether a particular instance 
of a Docking Object is visible to a particular node. The Primary Table has a Primary 
20 Row-ID value that is used to identify a row of the Primary Table being updated, 
deleted or inserted. For example, the "Opportunity Docking Object" may have as a 
primary table the table S_OPTY. The row-id of that table, i.e., S_OPTY.row_id, is 
the Primary Row-ID for the Opportunity Docking Object. 

25 Each dock object has a visibility level and a visibility level attribute that are 

analyzed using visibility rules. The valid values are 'Enterprise', 'Limited' and 
'Private.' All member table rows in an enterprise dock object are rq)licated to any 
nodes. Member table rows in limited dock objects are rq)licated to any nodes. 
Member table rows in limited dock objects are subject to visibility checks and are 

30 routed to nodes that have visibility to the rows. A Visibility Rule is a criterion that 
determines whether a particular instance of a Docking Object is "visible" to a 
particular node 21 . If a Docking Object is visible to a particular node, that node will 
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receive updates for data in the Docking Object. Visibility Rules are of two types, 
d^ending on the field RULE_TYPE. A Visibility Rule with a RULE_TYPE of "R" 
is referred to as an SQL Rule. An SQL Rule includes a set of Structured Query 
Language (SQL) statements that is evaluated to determine if any data meeting the 
5 criteria specified in the SQL statements exists in the Docking Object. If so, the 
Docking Object is visible to the node. A Visibility Rule with a RULE_TYPE of "O" 
is referred to as a Docking Object Rule. A Docking Object Rule specifies another 
Docking Object to be queried for visibility. If the specified Docking Object is 
visible, then the Docking Object pointing to it is also visible. 

10 

A Related Docking Object is a Docking Object that is propagated or deleted 
when the Docking Object under consideration is propagated or deleted. For example, 
an Opportunity Docking Object may have related Docking Objects representing the 
sales contacts, the organizations, the products to be sold, and the activities needed to 
15 pursue the opportunity. When an Opportunity Docking Object is propagated from 
Central Database 3 to one of node databases 23, the related docking objects are also 
propagated. 

Figure 2 depicts a database schema that shows the relationship of the various 
20 components that make up a Docking Object. The schema is a meta-database, in that 
it does not describe the data being accessed in the database. Rather, the schema is 
a separate database that defines the structure of the database being accessed. That is, 
it is a database comprising tables that describe the relationships and data contexts of 
another database. 

25 

Each of the tables shown m Figure 2 is a table in a relational database, and 
as such is in row-column form. Many columns represent fields that are common to 
all the illustrated tables. Such fields include for example, a ROW ID to identify a 
particular row in the table, as well as fields to track the date and time that a row was 
30 created and last modified, and the identity of the user who created or modified the 
row. In addition, each table contains fields specific to that table, and which are 
described in detail below. 
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Table S_DOBJ 61 describes the Docking Objects in an jqpplication. Table 
S_DOBJ 61 includes the fields OBJ_NAME and PRIMARY_TABUE_ID. Field 
OBJ_NAME defines the name of the Docking Object being described. Field 
PRIMARY_TABLE_ID is used to identify the primary table associated with this 
5 Docking Object. 

Table S_DOBJ_INST 63 describes whether a particular instance of a Docking 
Object, described by table S_DOBJ 61, is present on a particular node's database. 
Table S_DOBJ_INST 63 includes the fields NODE_ID, DOBJ_ID and 
10 PR_TBL_ROW_ID. Field NODE_ID points to a particular node table 65. Field 
DOBJJD points to the Docking Object to which the Docking Object instance applies. 
Field PR_TBL_ROW_ID is used to select a particular row in the Primary Table of 
the Docking Object. This value identifies the Docking Object instance. 

15 Table S_REL_DOBJ 67 describes the related Docking Objects of a particular 

Docking Object, described by table S_DOBJ 61. Table S_REL_DOBJ 67 includes 
the fields DOBJ_ID, REL_DOBJ_ID, and SQL_STATEMENT. Field DOBJ_ID 
identifies the Docking Object that owns a particular related Docking Object. Field 
REL_DOBJ_ID identifies the related Docking Object that is owned by the Docking 

20 Object identified by DOBJJD. Field SQL_STATEMENT is an SQL statement that 
may be executed to obtain the Primary ID value of the related Docking Object. 

Table S_DOBJ_TBL 69 describes the member tables of a particular Docking 
Object, described by table S_DOBJ 61. Table S_DOBJ_TBL 69 includes the fields 

25 DOBJJD, TBL_ID, and VIS_EVENT_FLG. Field DOBJ_ID identifies the Docking 
Object that contains the member table described by the row. Field TBLJD identifies 
the particular table in the database that is the member table described by the row. 
Field VIS_EVENT_FLG is a flag that indicates whether a change to this Docking 
Object can result in a visibility event. A value of "Y" indicates that a change can 

30 result in a visibility event; a value of "N" indicates that it cannot. 
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Table S_DOBJ_VIS_RULE 71 contains the visibility rules associated with a 
particular Docking Object. S_DOBJ_VIS_RULE 71 contains the fields DOBJJD, 
RULE_SEQUENCE, RULE_TYPE, SQL_STATEMENT and CHECK_DOBJ_ID. 
Field DOBJ_ID identifies the Docking Object with which a particular visibility rule 
5 is associated. Field RULE_SEQUENCE is a sequence number that indicates the 
sequence, relative to other visibility rules in table S_DOBJ_VIS_RIJL£ 71, in which 
the particular visibility rule should be run. RULE_TYPE specifies whether the 
particular visibility rule is of type "R," indicating an SQL visibility rule or of type 
"O," indicating a Docking Object visibility rule. 

10 

If RULE_TYPE is equal to "R," field CHECK_DOBJ_ID is not meaningftil, 
and field SQL STATEMENT contains an SQL statement that is evaluated using the 
Primary ROW-ID of the primary table associated with this Docking Object and a 
particular Node 21. If the SQL statement returns any records, the Docking Object 
15 is deemed to be visible to the Node 21 for which visibility is being determined. 

If RULE_TYPE is equal to "O," both field CHECK_DOBJ_ID and field 
SQL_STATEMENT are meaningftil. Field CHECK_DOBJ_ID specifies a docking 
object whose visibility should be determined. If the specified docking object is 
20 deemed to be visible, then the docking object associated with the visibility rule is also 
visible. Field SQL_STATEMENT contains a SQL statement that, when executed, 
returns the Row-ID of the docking object identified by CHECK_DOBJ_ID that 
corresponds to the docking object instance associated with the visibility rule. 

25 Table S_APP_TBL 73 is an Application Table that describes all the tables used 

in a particular application. It is pointed to by table S_DOBJ_TBL 69 for each 
member table in a docking object, and by table S_DOBJ for the primary table in a 
docking object. S_APP_TBL 73 points to table S_APP_COL 75, which is an 
Application Column Table that describes the columns of data in a particular 

30 application. S_APP_TBL 73 points to table S_APP_COL 75 directly through a 
primary key and indirectly through such means as a Foreign Key Column Table 81, 
User Key Column Table 83, and Column Group Table 85. The relationship of an 
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Application Table, Application Column Table, Foreign Key Column Table, User Key 
Column Table and Column Group Table are well known in the ait and are not further 
described. 

5 TTpdate Processing 

Figure 3 depicts steps performed by an update manager 31 such as update 
manager 31-a, 31-b or 31-c in updating a database, such as a node database 23-a, 23- 
b or 23-c, responsive to user input. Execution of update manager 31 begins in step 
101. In step 103, the update manager 31 accepts from the user input 33 in the form 

10 of a command requesting that the data in database 23 be altered. The request may 
be in the form of a request to delete a row of a table, to add a row to a table, or to 
change the value of a cell at a particular column of a particular row in a table. In 
step 105, using a well-known means, the update manager 31 applies the requested 
update to database 23. In step 107, the update manager 31 creates a log record 

15 describing the update and writes it to update log 35. 

The contents of a log record describe the update made. Each log record 
indicates the node identifier of the node making the update, an identification of the 
table being updated, and an identification of the type of update being made, i.e., an 

20 insertion of a new row, a deletion of an existing row, or an update to an existing 
row. For an insertion, the log record additionally includes an identifier of the row 
being inserted, including its primary key and the values of the other columns in the 
row. For a deletion, the log record identifies the primary key of the row being 
deleted. For an update, tiie log record identifies the primary key of the row being 

25 updated, the column within the row being updated, the old value of the cell at the 
addressed row and column, and the new value of the cell. 

After writing a log record in step 107, the update processor exits for this 
update. The foregoing description of the update processing preferably includes 
30 additional steps not material to the present invention, for example, to assure 
authorization of the user to make the update, to stage and commit the write to the 
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database to allow for rollback in the event of software or hardware failure, and the 
like. These stq)s are well-known in the art and are not described further. 

An update manager 11 executing in central computer system 1 operates in an 
S analogous manner, except that it updates central database 3 and writes its log records 
to central update log 11. 

Figure 4 depicts steps performed by a Docking Manager 25 such as Docking 

10 Manager 2S-a, 2S-b or 2S-c to transmit and/or receive one or more transaction logs. 
Docking Manager 25 is invoked by the user of a remote node such as node 21-a, 21-b 
or 21-c, whereby the user requests that the node dock with central computer 1 to 
upload an update log such as update log 35-a to central computer 1 , to download a 
partial log such as partial log 17-a, or both. Execution of Docking Manager 25 

15 begins in step 121 . In step 123, Docking Manager 25 connects with central computer 
1 under the control of Central Docking Manager 5. This connection can be any 
connection that enables data exchange. It is anticipated that the most common form 
of a connection is a telqjhone line used in conjunction with a modem, but other forms 
of data connection, such as a Local Area Network or a TCP/IP connection may also 

20 be used. Step 125 checks to see whether the user has requested that node update log 
35-a be uploaded to the Central Computer 1. If so, execution proceeds to step 127. 
If not, step 127 is skipped and control is given to step 129. In sxep 127, Docking 
Manager 25 uploads its update log to central computer 1. The upload may be 
accomplished with any known file transfer means, such as XMODEM, ZMODEM, 

25 KERMTT, FTP, ASCII transfer, or any other method of transmitting data. In step 
129, Docking Manager 25 checks to see whether the user has requested that a partial 
log such as partial log 17-a be downloaded from Central Computer 1 . If so, execution 
proceeds to step 131. If not, step 131 is skipped and control is given to step 133. 
In st^ 131, Docking Manager 25 downloads its partial log ftom central computer 

30 1 . The download may be accomplished with any known file transfer means, such as 
XMODEM, ZMODEM, KERMTT, FTP, ASCII transfer, or any other method of 
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transmitting data. In stq) 133, having completed the requested data transfer, Docking 
Manager 25 exits. 

Merge Processing 

5 Merge processing is performed by a processor such as node merge processor 

27-a, 27-b, or 27-c, or central merge processor 7. The merge process serves to 
update its associated database with a transaction that has been entered by a user of a 
computer remote from the computer where merge processing is being performed. 
Merge processing is analogous to update processing and is similar in form to update 

10 processing as previously disclosed with reference to figure 3, with three differences. 
First, the input to a merge processor is not an update entered directly by a user, but 
rather is a log file that is obtained from a computer remote from the computer where 
the merge is executing. A second difference is that, as shown by in Figure 1 , merge 
processing does not produce a log when performed at a node. The function of a log 

IS on a node is to record a transaction for propagation to Central Computer system 1 
and thence to other nodes as required. A transaction that is the subject of a merge 
in a node has been communicated to Central Computer System 1, and there is no 
need to re-communicate it. 

20 A third difference is that merge processing must be capable of detecting and 

resolving multiple conflicting transactions. For example, assume that a field contains 
the value "Keith Palmer." Assume further that a user at node 27-a enters a 
transaction to update that field to "Carl Lake," and a user at node 27-b enters a 
transaction to update the same field to "Greg Emerson." Without collision detection, 

25 data among various nodes may become conupt. When the transaction for user 27-a 
is merged, the field is updated from "Keith Palmer" to "Carl Lake." Without 
collision handling, when the transaction for node 27-b is merged, the field would be 
updated to "Greg Emerson, " and the central database would then be out of synch with 
the database of node 27-a. Furthermore, when merge processing is performed on 

30 each of nodes 27-a and 27-b, each node will update its database with the other's 
transactions, leaving at least one node out of synch with the other node and with 
central database. 
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Therefore, merge processing must also have a means of detecting collisions 
and correcting them. In the above example, a simple way to detect and correct a 
collision is to compare the value in the database to the value that the merge log 
reflects as being the previous value in the node database. If the two values do not 

5 match, Merge processor 7 may reject the transaction and generate a corrective 
transaction to be sent to the node firom which the conflicting transaction originated. 
In the above example, when the transaction for node 27-b was presented to merge 
processor 7, merge processor 7 would compare "Keith Palmer," the prior value of 
the field as recorded by node 27-b to "Carl Lake," the present value of the field as 

10 recorded in central database 3. Detecting the mismatch, mei;ge processor 7 may then 
generate a transaction to change the value "Greg Emerson" to "Carl Lake," and write 
that transaction to update log IS. 

The above is one example of a collision and a resulting corrective action. 
15 Other types of collisions include, for example, an update to a row that has previously 
been deleted, inserting a row that has previously been inserted, and the like. Merge 
processing must detect and correct each of these collisions. This may be performed 
using any of a number of well-known methods, and is not discussed further. 

20 Figure 5 dqiicts the steps performed by merge processor such as central merge 

processor 7. Although it depicts merge processor 7 writing to central database 3 and 
to transaction log 15, it is equally representative of a node merge processor such as 
node merge processor 27-a, 27-b or 27-c updating a node database 23-a, 23-b or 23- 
c. Merge processing begins at step 141. In stq) 143, merge processor 7 finds the 

25 first unprocessed transaction on received log 19. In step 147, merge processor 7 
selects a transaction from received log 19. In step 149, merge processor 149 attempts 
to update database 3 according to the transaction selected in step 147. In step 151, 
merge processor 7 determines whether the database update of step 149 failed due to 
a collision. If so, merge processor proceeds to step 153, which generates a corrective 

30 transaction. Following the generation of the corrective transaction, the merge 
processor returns to step 149 and again attempts to update database 3. If no collision 
was detected in step 151, execution proceeds to step 157. In step 157, merge 
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processing checks to see if it is executing on central computer 1 . If so, sxep 155 is 
executed to journal the transaction to log 15. In any case, either if step 157 
determines that the merge processing is being performed on a node or after step 155, 
execution proceeds to step 159. Step 159 checks to see if any transactions remain to 
5 be processed from log 19. If so, execution repeats from step 147, where the next 
transaction is selected. If not, merge processing exits in step 161. 

T^g Management 

Figure 6 depicts the steps to be performed by log manager 9 to prepare a 
10 partial transaction log such as partial transaaion log 17-a, 17-b, or 17-c. The 
procedure depicted in Figure 6 is executed for each node available to dock with 
central computer system 1. Log manager 9 begins execution in step 171. In step 
173, Log Manager 9 finds the first unprocessed transaction for the node whose partial 
transaction log is being prepared. In step 175, log manager 9 selects a transaction 
15 for processing. In step 177, log manager 9 checks to see whether the selected 
transaction originated on the same node for which processing is being performed. If 
so, there is no need to route the transaction back to the node, and control proceeds 
to step 179. Step 179 checks to see whether there are any transactions remaining to 
be processed. If so, control is given again to step 175. If not, control passes to step 
20 189, which records the last transaction that was processed for this node, and then 
exits at step 191 . If the transaction originates in other than the same node as the node 
for which processing is being performed, control is given to step 181. Step 181 calls 
a visibility calculator to determine whether the selected transaction is visible to the 
node being processed. The Visibility calculator routine is described in detail further 
25 herein. In step 183, log manager 9 checks to see whether tiie visibUity calculator 
determined that the transaction is visible. If it is not visible, contix)l is passed to step 
179, which performs as disclosed above. If the transaction is visible, control is 
passed to step 185. Step 185 writes a record for this transaction to die partial 
transaction log for the node being processed, for example, partial transaction log 17-a 
30 for node 21-a. In step 187, the log manager 9 records the last transaction that was 
processed for this node, and then passes contit)l to step 179, which determines 
whetiier to select additional transactions or exit, as disclosed above. 
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Visihilitv Calcailation 

Figure 7 <iq)icts a flowchart describing the process a visibility calculator for 
calculating visibility for a docking object as invoked by step 181 of log manager 9. 
The visibility calculator is called with the node-id of the node for which visibility is 

5 being calculated, the docking object for which the visibility is being calculated, and 
the row-id of the docking object whose visibility id being calculated. The visibility 
calculator uses this information, in conjunction with information obtained from meta- 
data stored in the schema depicted in Figure 2, to determine whether a particular 
transaction that updates a particular row of a particular docking object is visible to 

10 a particular node. 

The Visibility calculator begins execution at step 201. In step 203, the 
visibility calculator makes a default finding that the transaction is not visible. 
Therefore, unless the visibility calculator determines that a transaction is visible, it 
15 will exit with a finding of no visibility. In step 205, the visibility calculator selects 
the first visibility lule associated with the docking object. This is done by finding the 
table S_DOBJ_VIS_RULE 71 associated with the current Docking Object as pointed 
to by table S_DOBJ 61. In step 205, the visibility calculator selects die row of table 
S_DOBJ_VIS_RULE 71 with the lowest value for field RULE_SEQUENCE. 

20 

In step 207, the Visibility Calculator checks the field RULE_TYPE for a value 
of "R." The value of "R" indicates that the rule is a SQL visibility rale. If so, the 
Visibility Calculator proceeds to step 209. In step 209 the Visibility Calculator 
obtains a SQL statement from field SQL_STATEMENT and executes it. An example 
25 of such an SQL statement might be: 

SELECT 'X' FROM S_OFrY_EMP 
WHERE OPTY ID = -.PrimaryRowId 
AND E\fl» ID = tNodeld; 

30 

This SQL statement causes a query to be made of application table 
S_OPTY_EMP. The query selects any records meeting two criteria. First, the 
records selected must have a field OPTYJD, which is a row id or key, equal to the 
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Primary Row-ID of the Docking Object whose visibility is being determined. 
Second, the records selected must have a field EMP_ID, which may be for example, 
an identifier of a particular employee, equal to the Nodeld of the node for whom 
visibility is being determined. In ordinary language, this SQL statement will return 
5 records only if a row is found in a table that matches employees to opportunities, 
where the opportunity is equal to the one being updated, and the employee to whom 
the opportunity is assigned is the operator of the node. 

This is a simplistic example, provided for maximum comprehension. More 

10 complex SQL statements are possible. For example, the rule: 

SELECT 'X' FROM 
«&Table_Owner.S_ACCT_POSTN ap 
«feTable_Owner.S_EMP_POSTN ep 
WHERE ap.POSmON_ID = ep.POSITION_ID 
15 AND ep.EMP_ID = :NodeId; 

This rule queries the tables S_ACCT_POSTN (which relates a particular 
account with a particular position in the organization that is responsible for the 

20 account) and S_EMP_POSTN (which relates what employee corresponds to a 
particular position). The condition "ap.POSrnON_ID = q).POSrnON_ID" requires 
fmding a row in the account-to-position table that has the same position as a row in 
the employee-to-position table. The condition "ep.EMP_ID = :NodeId" further 
requires that the selected row in the employee-to-position table also have an Employee 

25 ID equal to the ID of the user of the Node for which visibility is being determined. 
In ordinary language, this condition allows visibility if the employee occupies the 
position that has responsibility for the account in the docking object being updated. 

There is no particular limit to the complexity of the conditions in the SQL 
30 statement used to evaluate visibility. Particular implementations of SQL may impose 
limitations, and resource considerations may make it desirable to use less complex 
statements, but these limitations are not inherent in the invention. 
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Step 211 evaluates whether the execution of SQL_STATEMENT in step 209 
returned any records. If records were returned, this indicates that the Node for which 
visibility is being checked has visibility to the docking object being processed. 
Accordingly, if records are returned, the Visibility Calculator proceeds to sxep 213. 

5 In step 213, the transaction is marked visible. Because no further rules need to be 
evaluated to determine visibility, the visibility calculator proceeds to step 228. Step 
228 synchronizes the databases by determining whether the calculated visibility 
requires the insertion or deletion of a docking object into a particular node's partially 
replicated database. This may occur, for example, if a node is determined to have 

10 visibility to a docking object due to a change to a related docking object. For 
example, an owner of a node may be assigned to a particular activity that is related 
to a particular sales opportunity. As a result, the node should be provided with a 
copy of the object representing the sales opportunity. 

15 Figure 8 depicts the steps performed to synchronize a partially replicated 

database in response to a change in data visibility. Execution begins in step 241 . In 
step 243, the Visibility Calculator references the visibility just calculated for a 
docking object. If the Docking Object is visible, execution proceeds to step 245. 
Step 245 references the S_DOBJ_INST table, to verify that a row exists for the 

20 Docking Object for the current node. If a row exists, this indicates that the node in 
question already has a copy of the referenced Docking Object, and the routine 
proceeds to step 255, where it exits. If, however, no row exists for the Docking 
Object at the node being processes, this indicates that the node in question does not 
have a copy of the Docking Object on its partially replicated database. The routine 

25 then proceeds to step 247, where a transaction is generated to direct the node to insert 
the Docking Object into its partially rqilicated database. 

If step 243 determines that the Docking Object is not visible, execution 
proceeds to step 249. Step 249 references the S_DOBJ_INST table, to verify that no 
30 row exists for the Docking Object for the current node. If step 243 determines that 
no row exists in the S_DOBJ_INST table for the current docking object for the 
current row, this indicates that the node in question does not have a copy of the 
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referenced Docking Object, and the routine proceeds to step 255, where it exits. If, 
however, a row exists for the Docking Object at the node being processed, this 
indicates that the node in question does have a copy of the Docking Object on its 
partially rqilicated database. The routine then proceeds to step 251, where a 
5 transaction is generated to direct the node to delete the Docking Object from its 
partially replicated database. 

Referring again to Figure 7, following the data synchronization routine of step 
228, the Visibility Calculator proceeds to step 229, where it exits. Referring to 
10 Figure 6, as previously described, the resulting fuiding of visibility is available to be 
checked by the log manager in step 183 to determine to write the transaction. 

Referring again to figure 7, if step 211 determines that no records were 
returned by the execution of the SQL statement in step 209, execution proceeds with 
15 step 215. Step 215 checks to see whether there are any remaining visibility rules to 
be assessed. If not, the visibility calculator proceeds to step 228 to synchronize the 
database, and then to step 229, where it exits. In this case, the default mark of no 
visibility that was set in step 203 remains set. This value will also be used by the log 
manager as shown in Figure 6, step 183, to determine not to write the transaction. 

20 

Referring again to Figure 7, if rules remain to be assessed, control proceeds 
to step 217, which selects the next rule to be processed. Control is then given again 
to step 207 to begin processing the new rule. 

25 The preceding text provided a description of the processing or SQL visibility 

rule; that is, visibility rules of type "R. " If step 207 determines that the visibility rule 
is not of type "R," the visibility rule is of type "O." Type "O" indicates a docking- 
object visibility rule. In such a case, the docking object being processed will be 
considered to be visible if it is related to a particular related docking object that is 

30 visible. If field RULE_TYPE is not equal to "R," then, execution proceeds to step 
221. Step 221 determines the related Docking Object whose visibility must be 
determined to determine whether the current docking object is visible. The related 
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Docking Object identifier is obtained from field CHECK_DOBJ_ID in table 
S_DOBJ_VIS_RULE 71 . In stq) 223, the Visibility Calculator determines which row 
in the related Docking Object must be queried for visibility. In order to determine 
this, the Visibility Calculator obtains a predetermined SQL statement from the field 
5 SQL_STATEMENT and executes it. The SQL statement is a query that select one 
or more rows of the Docking Object that, for example, correspond to the docking 
object for which the Visibility Calculator was invoked. 

For example, assume that it is desired to indicate that a record for a sales 

10 opportunity should be visible if the Node has visibility to any sales quote made for 

that sales opportunity. This may be accomplished using the following SQL statement: 

SELECT ''ROW_ID" FROM 

&Table_Owner . S_DOC_QUOTE 
WHERE OPTY_ID=:Primary Rowld 

15 

This SQL statement accesses a table S_DOC_QUOTE that contains all sales 
quotes. The WHERE clause specifies retrieval of all rows where the Opportunity ID 
of the row is equal to the Row-ID of the opportunity for which visibility is being 
20 calculated. The Visibility manager retrieves the specified Row-Ids, thereby 
identifying the rows of the S_DOC_QUOTE table whose visibility must checked. 

Having determined the a related docking object and the row-ID of that related 
docking object upon whose visibility the visibility of the current docking object 

25 depends, the Visibility Calculator proceeds to step 225. In stsp 225, the Visibility 
Calculator recursively invokes itself to determine visibility of the related docking 
object. The recursively invoked Visibility Calculator operates in the same manner 
as the Visibility Calculator as called from the Log Manager 9, including the capability 
to further recursively invoke itself. When the recursive call concludes, it remms a 

30 visibility indicator for the related Docking Object, and control proceeds to step 227. 
In step 227, the Visibility calculator determines whether the related Docking Object 
was determined to have been visible. If so, the Visibility Calculator proceeds to step 
213 to mark the originally current Docking Object as visible, and then to step 228 to 
synchronize the database and then to step 229 to exit. If the related Docking Object 
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was not detennined to be visible, control proceeds to step 215 to determine whether 
additional visibility rules remain to be assessed. 

The Visibility Calculator, in conjunction with the Log Manager is therefore 
5 able to determine what subset of update transaction data is required to be routed to 
any particular node. This operation serves to reduce the transmission of unneeded 
data from the Central Computer 1 to the various nodes such as nodes 21-a, 21-b and 
21-c that utilize partially replicated databases, and to reduce the system resources 
such as disk space needed to store, and the CPU time needed to process, what would 
10 otherwise be required to maintain a fully replicated database on each remote node. 

The operation of the log manager 9 in conjunction with the Visibility 
Calculator herein described will be apparent from reference to the description and to 
the drawings. However, as a further aid in the description of these facilities, a 
15 pseudocode representation of these facilities is hereto attached as an Appendix. 

Batrh Vkihilitv Calculation 

The calculation of visibility events and the routing of visible transactions may 
be optimized by batching related SQL statements, rather than performing successive 

20 row-by-row operations. This optimization is achieved by eliminating redundant 
operations, using set processing and reducing network traific. Redundant work is 
eliminated by denormalizing key data used to calculate visibility into the transaction 
log. For example, the Log Manager the docking object, primary table id, visibility 
event flags, and related data are stored in the transaction log table. Instead of 

25 calculating this data once for every mobile client, Log Manager calculates this data 
once for all mobile clients to use. Log Manager uses set processing by submitting 
SQL statements to check the visibility of many thousands of transactions 
simultaneously instead of submitting a SQL statement for each transaction. Network 
traffic is reduced by retrieving only the visible transactions from the database server 
30 to the docking server. Consequently, significantly less data travels over the network 
from the database server to the docking server. 
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Figure 9 dapicts the structure of the database design of the Transaction Log 
Table 300 used to support batch visibility checking. Node table 301 is the central 
table of the database, and contains one-to-many pointers to Dock Object Instance table 
302, Dock Status table 304, and Transaction table 306. 

5 

Docking Object Instance table 302 stores whether a docking object instance 
is visible to a mobile client and has been downloaded to the mobile client. A row 
exists in Docking Object Instance table 302 if the docking object instance is fiilly 
visible or partially visible to the mobile client. If the docking object is not visible, 
1 0 then a row for the docking object instance does not appear in Docking Object Instance 
table 302. Docking Object Instance table 302 (S_DOBJ_INST) comprises the 
following fields to support batch visibility checking: 

NODE_ID: a non-null user key of the node to which this docking 
IS object instance relates. 

DOBJ_ID: a non-null user key of the docking object to which this 
docking object instance relates. 

PR TBL ROW ID: a non-null user key containing the Row_ID of the 
primary table in the docking object. This value identifies the Docking Object 
20 Instance. 

STAT_Flag: a one-byte flag containing the value 'F' or 'P'. The 
value 'F' indicates that the docking object instance is fully visible. The value 
'P' indicates that the docking object instance is partially visible. 

LAST_CHK_TXN_ID: the transaction ID of the transaction in which 
25 the visibility of the dock object instance was last checked. This value may be 

used to determine when the dock object instance must be recalculated. For 
example, if LAST_CHK_TXN_ID = 3000, then Log Manager should not re- 
calculate visibility of the dock object instance until a visibility event occurs 
after transaction ID 3000. 

30 

Dock Stams table 304 stores status information relating to each mobile client. 
This includes the identity of the last file merged, the last file extracted, and the last 
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transaction extracted. Dock Status Table 304 (S_DCK_STAT) comprises the 
following fields to support batch visibility checking: 
ROW_ID: primary key. 

NODEJDD: Identity of the mobile client that owns this status 
S information. 

TYPE: This field is used to interpret the VAL field, and contains one 
of the strings "EXTRACT_RECORD" , "LOG_EXTRACT", 
"MERGE_RECORD", "LAST_MERGE", or "SESSION". 

VAL: This field contains the value corresponding to the data type in 
10 the TYPE field. 



In addition, this table records the last transaction processed by an executable 
program called the Log Preprocessor. This is indicated in the VAL field for a row 
witii a ROW_ID of zero and a TYPE of "EXTRACT_RECORD" . 

15 

Transaction table 306 stores transaction that may need to be routed to all 
raobUe cUents. Transaction table 306 (S_DCK_TXN_LOG) comprises tiie foUowing 
fields to support batch visibility checking: 

TXN_ID: A non-null primary key tiiat identifies the transaction. 
20 DOBJ_ID: a non-null user key of the docking object to which this 

docking object instance relates. 

PR_TBL_ROW_ID: a non-null user key containing the Row_ID of the 
primary table m the docking object. This value identifies the Docking Object 
Instance. 

25 VIS_EVT_FLG: This field contains either the value 'Y' or 'N', and 

indicates whether the transaction causes a visibility event. 

VIS_LEVEL_FLG: This field mdicates the visibility level of the dock 
object. A value 'L' indicates that the dock object has limited visibility. A 
value of 'P' indicates that the dock object is private. A value of 'E' indicates 

30 that this object has enterprise visibility. 
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Batch visibility checking executes in four phases. Briefly, Phase 1 is nin one 
for each transaction in Transaction Log Table 300 and denormalizes the transaction 
log data into the constituent tables. Phase 2 is run once per mobile client per 
iteration, and checks for visibility events for a mobile client. Phase 3 is run once per 
S mobile client per iteration, and extracts visible transactions for the mobile client. 
Phase 4 is run once per iteration and deletes transactions ^m Transaction Log Table 
300. Detailes of all four phases are described below. 



In an embodiment of the present invention, phases 1 and 4 may be combined 
10 into a single executable program called the Log Preprocessor. Only one Log 
Preprocessor is run against an installation at any one time. Phases 2 and 3 may be 
combined into a single executable program called the Log Router. One or more Log 
Routers may be run against a single installation concurrently. The Log Router 
program may use semaphores to prevent more than one Log Router from routing 
IS transactions to the same mobile client simultaneously. 



Phase 1 is run one for each transaction in Transaction Log Table 300 and 
denormalizes the transaction log data into the constituent tables. This phase 
denormalizes values in S_DCK_TXN_LOG based on transaction log data. The 
20 following pseudocode describes the operation of Phase 1 in detail: 



DoPhaselO 
{ 

~ Get stams values so we can identify which txns to pre-process 
25 Get max(TXN_ID) from S_DCK_TXN_LOG 

Get TXN_PROCESSED_ID from S_DCK_STAT for Node id 0 

numTxns : = 0; 

- SELECT tl.* 

30 - FROM S DCK_TXN_LOG U 

- WHERE TON_ID > max(TXN_PROCESSED_ID) 

- AND TXN_ID < = maxCrXN_ID) 

- ORDER BY TXN_ID ASC 

FOR each txn between max(TXN_ID) and TXN_PROCESSED_ID LOOP 
35 - If the client program already calculated the denormalized 

- columns, then we don't have to do it again. 
IF tl.DOBJ_ID is not null THEN 
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continue; 
END IF; 

FOR each operation in the txn LOOP 
5 - Use UTUdSqlO to get primary table rowjds 

- Assumes that each txn can only have one primary row_id 
FOR each primary id row LOOP 

IF operation is a visibility event THEN 

p_vis_evt_flg := 'Y'; 
10 ELSE 

p_vis_evt_flg := 'N'; 
END IF; 

update S_DCK_TXN_LOG 
15 set (DOBJ_ID, PR_TBL_ROW_ID, VIS_EVT_FLG) 

= (DOBJ_ID, PR_TBL_ROW_ID, p_vis_evt_flg) 
where TXNJD = current txnjd; 
END IF; 
END LOOP; ~ each operation 
20 numTxns := numTxns + 1; 

END LOOP; - each txn 

- Commit after every N txns 
IF numTxns > maxTxns THEN 

25 Set TXN_PROCESSED_ID = current TXN_ID 

commit; 
numTxns : = 0; 
- lock the row again 

Get TXN_PROCESSED_ID from S_DCK_STAT for Node id 0 
30 END IF; 

END LOOP; - for loop 



Phase 2 is run once per mobile client per iteration, and checks for visibility 
35 events for a mobile client. This phase looks for all visibility event transactions and 
recomputes visibility. It looks for the next set-based transactions in order to limit the 
current iteration to a reasonable amount of processing. The phase downloads and 
removes Docking Obect instances in response to visibility changes and stores the 
visibility of Docking Object instances.in table S_DOBJ_INST 63. The following 
40 pseudocode describes the operation of Phase 2 in detail: 



ProcessVisibiUtyEvent (DOBJ_ID, PR_TBL_ROW ID, STAT FLG) 
{ 

- If we have already calculated visibility for this dobj 
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- instance in this iteration, then we do not need to 
-- recheck visibility. 

IF already check visibility for this dobj mstance THEN 
return; 
5 END IF; 

- Flush the S_DOBJ_INST table cache 
CaU UTLNodeDObjInstHushO 

10 - Compute visibility 

Run SQL rules, Check Dock Object rules. 

- Reconcile S_DOBJ_INST table and do downloads/removes as needed 

- If visibility has changed, stuff the value of TXN_PROCESSED_ID 
15 - into S_DOBJ.LAST_CHK_TXN_ID 

~ NOTE: we can also stuff in the value of max(TXN_ID) so we do not 
download txns affecting the dobj instance until after the 
current max(TXN_ID) 

Call LOGReconcileDObjInstO 

20 } 

DoPhase2 (NODE_ID) 
{ 

- Get status values so we can identify which txns to pre-process 
25 Get VIS_CHECK_RECORD from S_DCK_STAT 

- new status for vis checks high water mark 
Get TXN_PROCESSED_ID from S_DCK_STAT for Node Id 0 

~ Don't do anything if there are no new txns to process 
30 IF TXN_PROCESSED_ID = VIS_CHECK_RECORD THEN 
return; 
END IF; 

Open the .dx file for writing 

35 

- Get visibility event txns, and load visibility 

- cache simultaneously 

- SELECT a.TXN_ID, U.OPERATION, U.VIS_EVT_FLG, 

U.DOBJ_ID, tl.PR_TBL_ROW_ID, di.STAT_FLG, 
40 -- di.LAST CHK_TXN_ID 

- FROM S_DdBJ INST di, 

S_DCK_TXN_LOG ti 

- WHERE U.TXN_ID > VIS_CHECK_RECORD 

- AND tl.TXN_ID < = TXN_PROCESSED_ID 

45 - AND U.TXN~ID < = VIS_CHECK_RECORD + batch_size 
~ (Oracle & Informix) 

- AND (tl.OPERATION in ('i', 'u') // set-based txn 

or tl.VIS_EVT_FLG = 'Y') 
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-- AND tl.PR_TBL_ROW_ID = (Ii.PR_TBL_ROW_ID (+) 

- AND ti.DOBJ_ID = di.DOBJ_ID (+) 

- AND tl.VIS_LEVEL_FLG = 'L' /* limited visibility */ 

- AND di.NODE_ID (+) = :node_id 

5 - AND TXN_ID > di.LAST_CHK_TXN_ID 

- ORDER BY tl.TXN_ID 

- NOTE: on Sybase, use set rowcount to limit batch size 

On Oracle & Infonnix, we assume that not many TXN_ID 
values are lost if the db server crashes and restarts. 

10 

numTxns := 0; 

Set VIS_CHECK_RECORD := old VIS_CHECK_RECORD; 
FOR each vis event txn or set-based txn in the batch LOOP 
~ We got a set-based txn 
15 PiocessVisibilityEvent (tl.DOBJ_ID, 

ts.PR_TBL_ROW_ID, di.STAT_FLG) 
END IF; 

IF amount written to .dx file > direshold THEN 
20 Close and compress the .dx file 

Increment LOG_EXTRACT counter in S_DCK_STAT 
Add .dx file to list of files that were written 
(do not write to server.tx file yet) 

END IF; 

25 

Set VIS_CHECK_RECORD = currentjxnjd 

END LOOP; 

30 IF Phases is separate program THEN 

~ Do this part if Phase 3 is a separate program 

IF txns were downloaded/removed to the current .dx file THEN 

Close and compress the .dx file 

Increment LOG_EXTRACT counter in S_DCK_STAT 
35 Add .dx file to list of files that were written 

(do not write to server.tx file yet) 
ELSE 

Delete the .dx file 
END IF 

40 

Write all .dx files to the server.tx file 

~ Commit at the end of the batch 
commit; 
45 END IF; 
} 
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Phase 3 is run once per mobile client per iteration, and extracts visible 
transactions for the mobile client. The following pseudocode describes the operation 
of Phase 3 in detail. 



5 DoPhase3 (NODE_ID) 
{ 

IF Phase2 is a separate program THEN 

Open the .dx file for writing 
END IF; 

10 

- Get status values so we can identify which txns to extract 
Get VIS_CHECK_RECORD from S DCK_STAT 

Get EXTRACT_RECORD from S_DCK_STAT 

15 -- SELECT tl.TXN_ID 

- FROM S_DCK_TXN_LOG tl 

- WHERE tl.TXN_ID > EXTRACT_RECORD 

- AND U.TXN_ID < = VIS_CHECK_RECORD 
AND (tl.VIS EVT_FLG = 'E' /* enterprise visible */ 

20 - or (tl.VIS_EVT_FLG = 'L' /* limited visible */ 

- and exists 

(select 'visible' 
from S_DOBJ_INST di 
where tl.DOBJ_ID = di.DOBJ_ID 
25 - and U.PR_TBL_ROW_ID = di.PR_TBL_ROW_ID 

and di.NODE_ID = 'nodejd' 
and a.TXN_ID > di.LAST_CHK_TXN_ID) 

) 

) 

30 - ORDER BY TXN_ID ASC 
numTxns := 0; 

FOR each visible txn between EXTRACT_RECORD and VIS_CHECK_RECORD 
LOOP 

35 Write the txn to the .dx file 

numTxns := numTxns + 1; 

IF amount written to .dx file > threshold THEN 
Close and compress the .dx file 
40 Increment LOG_EXTRACT counter in S_DCK_STAT 

Add .dx file to list of files that were written 
(do not write to server.tx file yet) 
END IF; 
END LOOP; 

45 

Set EXTOACT_RECORD = VIS_CHECK_RECORD; 
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IF txns were downloaded/removed/ written THEN 
Close and compress the .dx file 
Increment LOG_EXTRACT counter in S_DCK_STAT 
Add .dx file to list of files that were written 
S ELSE 

Delete the .dx file 
END IF 

~ Commit at the end of the batch 
10 commit; 

Phase 4 is run once per iteration and deletes obsolete transactions from 
Transaction Log Table 300, including its substituent Transaction table 306 and Set 
Transaction ID table 308. The following pseudocode describes the operation of Phase 
15 4 in detail. 



DoPhase4 () 

— Get status values so we can identify which txns to delete 
20 Get max(EXTRACT_RECORD) from S_DCK_STAT 

Get max(EXTRACT_RECORD) from last iteration 

~ No new txns to delete 

IF max(EXTRACT_RECORD) = last iteration THEN 
25 return; 

END IF; 

- DELETE FROM S_DCK_TXN_LOG 

-- WHERE TXN_ID < = max(EXTRACT_RECORD) 
30 Delete from S_DCK_TXN_LOG 

~ Commit at the end of the batch 
commit; 

35 

VisibiUtY Caching 

Improved performance may be obtained by providing a cjq)ability of caching 
recent visibility events. The S_DOBJ_INST table 63 is particularly suitable to 
provide such a "visibility cache." The existence of a particular docking object 
40 instance in S_DOBJ_INST table 63 may be used to assert that the docking object 
instance is visible to the mobile client. 
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The visibility cache improves perfonnance in two ways. First, it reduces the 
number of times visibility must be calculated. Log Manager 9 can use the cache in 
memory to determine visibility of a docking object instance when the transaction is 
on a table that does not cause implicit visibility events (i.e. the 
5 VISIBILrrY_EVT_FLG is not checked for the table). Log Manager does not need 
to run any visibility SQL statements to determine the visibility of the transaction. 
Note that, if a transaction affects a table that can cause a visibility event, Log 
Manager must re-run the visibility SQL statements to determine that transaction's 
visibility. 

10 

Second, the visibility cache reduces the number of SQL statements executed 
per visibility calculation. Log Manager uses the cache to determine visibility of check 
docking objects. Log Manager does not need to recursively run visibility rule SQL 
statements on each check docking object instance to determine the visibility of the 
15 transaction. Instead, Log Manager 9 joins to the S_DOBJ_INST table 63 to determine 
the visibility of check docking objects. 

As discussed earlier, the log manager uses two types of visibility rules, which 
can be summarized as SQL rules and Check-docking-object rules. An SQL rule is an 

20 SQL fragment that expresses whether the docking object instance is visible. An 
example of a visibility condition specified by an SQL rule for the opportunity docking 
object is "An Opportunity is visible if the sales rep is on the sales team." A check- 
docking-object rule indicates that a docking object instance is visible if another 
docking object is visible. The definition of a check-docking-object rule contains a 

25 SQL fragment that tells the Log Manager how to get all the check docking objects for 
the docking object instance. An example of a visibility condition specified by a check- 
docking-object rule for the opportunity docking object is "An Opportunity is visible 
if the Opportunity is used by a Quote that is visible to the sales rep." 

30 SQL rules are relatively inexpensive in execution resources. In contrast, 

Check-docking-object rules consume more resources and are therefore more 
expensive. In order to execute a check-docking-object rule, Log Manager recursively 
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runs visibility SQL statements for the docking object it is checking. Determining 
visibility of a transaction can require running hundreds, or even thousands of SQL 
statements. Some objects may have eight to ten check-docking-object rules. Running 
all the visibility rule SQL statements for these objects could take between 0.25 
5 seconds and several seconds for each mobile client. As the number of mobile clients 
increases, this can lead to undesirably low levels of service. 

Log Manager also uses the S_DOBJ_INST table to track whether a docking 
object instance (e.g., a particular Opportunity instance) has been downloaded to a 
10 mobUe cUent. The S_DOBJ_INST table prevents Log Manager from downloading a 
docking object instance that was already previously downloaded, or removing a 
docking object instance that was already previously removed. 

The visibility cache is implemented in two ways. First, the S_DOBJ_INST 
15 table is used for transactions on non-visibility event tables. When checking visibility 
of a transaction, if the transaction is on a table that does not cause visibility events 
(S_DOBJ_TBL.VIS_EVT_FLG = 'N'), then the S_DOBJ_INST table is used to 
determine if the docking object instance is visible. If the docking object instance of 
the transaction exists in the S_D0B3_INST table, then the transaction is visible to the 
20 mobile client. Otherwise, the transaction is not visible to the mobile client. The 
benefit is that the Log Manager does not need to run any visibility SQL rules or 
check-docking-object rules to determine the visibility. 

Second, the S_DOBJ_INST table is used to determine visibility of check- 
25 docking-objects. Most of the check-docking-object rules may be converted to SQL 
rules that join the check-docking object to the S_DOBJ_INST table. If any check- 
docking object exists in the S_DOBJ_INST table, then the check-docking object must 
be visible to the mobile client. The benefit is that the Log Manager runs at most one 
SQL statement to determine visibility of a check-docking object. 

30 
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The following example shows the benefits of the visibility cache. Without the 
visibility cache, the set of rules used to check visibility of a docking object 
representing an account might be expressed as the following four niles. 

5 Rule 1 (SQL): Account is visible if Account is a competitor: 
primary_table.CMPT_FLG = 'Y' 

Rule 2 (SQL): Account is visible to sales rep if sales rep is on the Account Team: 

exists (select 'X' from S_ACCNT_POSTN ap, S_EMP_POSTN ep 
10 where ap.OU_EXT_ID = primaryjable.ROW_ID 

and ep.EMP_ID = :person_id) 

Rule 3 (Check-Docking-Object): Account is visible if it is an account for an 

Opportunity that is visible: 

15 select OPTY_ID from S_OPTY_ORG oo 

where OU_ID = :primary_row_id 

Rule 4 (Check-Docking-Object): Account is visible if it is an account for a Quote that 
is visible: 

20 select ROW_ID from S_DOC_QUOTE 

where OU_ID = :primary_row_id 

To check the visibility of an Account docking object without a visibility cache, 
25 Log Manager performs the following steps to generate and execute SQL statements 
based on the above visibility rules. 



Step 1: OR together the SQL rules and execute the result: 



select 'X' from S_ORG_EXT primary_table 

where primary_table.ROW_ID = :primary_table_row_id 
and ((primaiy_table.CMPT_FLG = 'Y') 

or exists (select 'X' from S_ACCNT_POSTN ap, S_EMP_POSTN 

where ap.OU_EXT_ID = primaty_table.ROW_ID 
and ep.EMP_ID = :person_id) 
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Step 2: Execute Rule 3, the check-docking-object rule for the Opportunities object: 

select OPTY_ID from S_OPTY_ORG oo 
where OU_ID = :primary_row_id 

For each opportunity retrieved, execute the visibility rule SQL statements 
(SQL rules and check docking object rules) to determine whether the opportunity is 
visible. This can be many SQL statements. 



10 Step 3: Execute the check docking object rule for the Quotes object: 

select ROW_ID from S_DOC_QUOTE 
where OU_ID = :primary_row_id 



15 For each quote retrieved, the visibility rule SQL statements (SQL rules and 

check docking object rules) are executed to determine whether the quote is visible. 
This can be many SQL statements. 



The total number of SQL statements executed by this process may be 
20 computed as 1 + (Opty Check Objs * Opty vis rules) + (Quote Check Objs * C?uote 
vis rules). This may be anywhere from one statement to several hundred statements, 
depending on the number of Opportunity and Quotes objects retrieved. 

With the visibility cache, the set of rules used to check visibility of a docking 
25 object representing an account might be expressed as the following four rules. The 
two SQL rules 1 and 2 are unchanged; the two check-dock-object rules have been 
rqjlaced with SQL rules that interrogate the S_DOBJ_INST table. 



Rule 1 (SQL): Account is visible if Account is a competitor: 
primary_table.CMPT_FLG = 'Y' 

Rule 2 (SQL): Account is visible to sales rep if sales rep is on the Account Team: 

exists (select 'X' from S_ACCNT_POSTN ap, S_EMP_POS'm ep 
where ap.OU_EXT_ID = primary_table.ROW_ID 
and ep.EMP_ID = :person_id) 
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Rule 3 (SQL): Account is visible if it is an account for an Opportunity that is visible: 

exists (select 'X' from S_OPTY_ORG oo, S_DOBJ_INST di 
where oo.OU_ID = :primary_row_id 

and oo.OPTY_ID = di.PR_TBL_ROW_ID 
5 and cU.DOBJ_ID = :dobjid and di.NODE_ID = :nodeid) 

Rule 4 (SQL): Account is visible if it is an account for a Quote that is visible: 

exists (select 'X' from S_DOC_QUOTE q, S_DOBJ_INST di 
where q.OU_ID = :primary_n)w_id 
10 and q.ROW_ID = di.PR_TBL_ROW_ID 

and di.DOBJ_ID = :dobjid and di.NODE_ID = :nodeid) 



To check the visibility of an Account docking object using a visibility cache, 

15 Log Manager generates and executes a single SQL statement derived from the four 

SQL rules. Log manager Ors together all four SQL rules to obtain a single SQL 

rule, as follows: 

select 'X' from S_ORG_EXT primary_table 

where primary_table.ROW_ID = :primary_table_row_id 
and ((primary_table.CMPT_FLG = 'Y') 

or exists (select 'X' from S_ACCNT_POSTN ap, S_EMP_POSTN 

where jq).OU_EXT_ID = primai7_table.R0W_ID 
and ep.EMP_ID = :person_id) 
or exists (select 'X' from S_OPTYJDRG oo, S_DOBJ_INST di 
where oo.OU_ID = :primary_row_id 

and oo.OPTY_ID = di.PR_TBL_ROW_ID 
and di.DOBJ_ID = :dobjid and di.NODE_ID = :nodeid) 
or exists (select 'X' from S_DOC_QU0TE q, S_DOBJ_INST di 
where q.OU_ID = :primary_row_id 

and q.ROW_ID = di.PR_TBL_ROW_ID 
and di.DOBJ_ID = :dobjid and di.NODE_ID = :nodeid) 



35 This single SQL statement accomplishes the same result as the potentially 

hundreds of SQL statements that would be required without the visibility cache. 



Because the SQL statements can get very large, it is advisable to establish a 
limit to the number of SQL rules that will be ORed together by Log Manager. This 
40 limit is preferably parameter-driven to permit ease of customization for a particular 



25 
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configuration. In some implementations, it may be useful to limit the number of 
tables in the SQL statement to about 16. 



The following SQL fragments each provide a mechanism for joining to the 
5 S_DOBJ_INST table. The fragment that is best for a particular implementation may 
vary depending on the performance characteristics for that implementation. 

Alternative 1: 

or (exists (select 'X' from S_OPTY_ORG oo, S_DOBJ_INST di 
10 where oo.OU_ID = :primary_row_id 

and oo.OPTY_ID = di.m_TBL_ROW_ID 
and di.DOBJ_ID = xheckdobjid 
and di.NODE ID = rnodeid) 

) 

15 

Alternative 2: 

or (exists (select 'X' from S_DOBJ_mST di 
where di.DOBJ_ID = :checkdobjid 
and di.NODE_ID = :nodeid 
20 and di.PR_TBL_ROW_ID in ( 

select OPTY_ID from S_OPTY_ORG oo 
where oo.OU_ID = :primary_row_id)) 

) 

25 Alternative 3: 

or (exists (select OPTY_ID from S_OPTY_ORG oo 
where oo.OUJD = :primary_row_id 
and OPTY_ID in 

(select PR_TBL_ROW_ID from S_DOBJ_INST di 
30 where di.NODE_ID = :nodeid 

and di.DOBJ_ID = xheckdobjid 
and di.STATUS_FLG = rvistype)) 

) 

35 The following pseudocode shows the algorithm for the visibility checking 

engine using tiie visibility cache. The algoiitirai is documented as four routines, 
denoted as CheckTxnVisibiUty, CheckObjectVisibility, CheckSqlRule and 
CheckOtherRule. 
CheckTxnVisibilitv 

40 - Check if a record in the txn log is visible to a LaptopNodeld 
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- Also processes implicit visibility events and related dock objects 

static BOOL CheckTxnVisibility (LaptopNodeld, Table, Rowld, *peVisible) 

{ 

Find the Table in the Dictionary; 
IF Table not found TEEN 

Error: Table not defined 
END IF; 

- set to not visible by default 
•peVisible = 'None'; 

FOR all docking objects that the table belongs to LOOP 

- Generate SQL to get Primaryld values of the Docking Object 
GeneratePrimaryldSQL (Table, Rowld, DockingObject); 
FOR each Primaryld value retrieved LOOP 

- Enhancement #1: use cache for non-visibility events 

- txn is for a table that does not cause visibility 

- events and the txn is not an insert on the dock object's 

- primary table (this is a new dock object instance). 

- Do not need to do visibility calculation. No implicit 

- visibility events and no related dock object processing 
IF Table. visibilityEventFlag = 'N' 

&& not an insert into DockObjectPrimaryTable THEN 

Find the object instance in the S_DOBJ_INST table 
IF status = 'Full' THEN 

*peVisible = 'FuU' 
ELSIF status = 'Partial' THEN 

*peVisible = 'Partial' 
ELSE 

*peVisible = 'None' 
END IF; 
ELSE 

— Must recalculate visibility 

CheckObjectVisibility (LaptopNodeld, PrimaryTable, 
PrimaryRowId, depth = 0, peVisible); 
END IF; 

~ Process implicit visibility events and related dock objects 
ReconcileObjectlnstance (LaptopNodeld, PrimaryTable, 
PrimaryRowId, &eVisible); 

- If we need to process implicit visibility events, then 
~ continue looping through all docking objects even if we 
~ already know that the Txn is visible. 
IF *peVisible in ('Full', 'Partial') THEN 
IF Table.visibilityEventFlag = 'N' THEN 
return TRUE; 
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END IF; 
END IF; 
END LOOP; 
END LOOP; 

return TRUE; 

} 

CheckObiectVisibilitv 

~ Check if a docking object instance is visible to the laptop user. 

BOOL CheckObjectVisibility 

(Nodeld, DObjName, PrimaryRowId, depth, *peVisible) 

{ 

~ Algorithm: 

- Check FULL visibility 

~ Use SQL Rules ORed together 

-- Use Check Dock Object Rules one by one 

- Check PARTIAL visibility (iff depth = = 0) 

- Use SQL rules OR-ed together 

~ Use Check Dock Object Rules one by one 



- Flush the visibility cache to the S_DOBJ_INST table because 

~ the SQL rules wiU reference the cache. 

Flush the visibility cache to the S_DOBJ_INST table. 

30 - Object is not visible. 

*peVisible = None; 

-- Check Visibility using SQL_RULES ORed together 
CheckSqlRule (Nodeld, DObjName, PrimaryRowId, peVisible, 
35 depth, UTL_VIS_FULL); 

IF *peVisible = = UTL_VIS_FULL THEN 
goto done; 

~ Check Visibility using Check Docking Objects 
40 CheckOtherRule (Nodeld, DObjName, PrimaryRowId, peVisible, 

depth, UTL_VIS_FULL); 
IF *peVisible == UTL_VIS_FULL THEN 
goto done; 

45 IF depth == 0 THEN 

/* Check Visibility using SQL_RULES ORed together */ 
CheckSqlRule (Nodeld, DObjName, PrimaryRowId, peVisible, 
depth, UTL_VIS_PARTIAL); 
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IF *peVisible = = XJTL_VIS_PARTIAL IHEN 
goto done; 

/* Check Visibility using Check Docking Objects */ 
5 CheckOtherRule (Nodeld, DObjName, PrimaryRowId, peVisible, 

depth, UTL_VIS_PARTIAL); 
IF *peVisible = = UTL_VIS_PARTIAL THEN 

goto done; 
ENDBF; 

10 

done: 
return TRUE; 

} 

15 Ch gg kSq l R wl g 

BOOL CheckSqlRule (Nodrfd, DObjName, PrimaryRowId, peVisible, 
depth, eVisType) 



{ 



- Create the SQL statement 

- "SELECT 'X' from <PrimaTyTable> pt where 

- pt.ROWJD = < primary table row id>" 

WHILE (TRUE) LOOP 

~ Build the SQL statement by ORing the SQL rules together. 
FOR each visibility rule for the Docking Objea LOOP 
-- Only append SQL statements that match the VisType 

- (Partial or Full) 

IF RuleType ! = SQLRule j | RuleLocalFlag ! = eVisType THEN 

continue; 
END IF; 

- Limit number of rules per statement to the one 
~ specified in the system preference. 

IF number_rules_appended = "LOG: vis rules per Stmt" THEN 

break; 
END IF; 

~ Add " <sql fragment > " to sql statement 
append the SQL rule to the sql statement; 
END LOOP; 

~ Run the sql statemmt 

Run the select SQL statement using PrimaryRowId; 
IF any rows returned THEN 

- row is visible 
♦peVisible = eVisType; 
goto done; 
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ENDEF; 

~ Stop if no more rules to run 
IF no more rules to append THEN 
5 break; 

END IF; 

END WHILE; 

10 done: 

return TRUE; 

} 

rheckOtherRule 

BOOL CheckOtherRule (Nodeld, DObjName, PrimaryRowId, peVisible, 
depth, eVisType) 

{ 

- Run check docking object rules 
20 FOR each visibility rule for the Docking Object LOOP 

- Only run sql statements that match the VisType 

- (Partial or Full) 

IF RuleType ! = CheckDockObjectRule 
1 1 RuleLocalFlag ! = eVisType THEN 
25 continue; 

END IF; 

Run the ParameterSQL using PrimaryRowId to get newPrimaryRowId 
FOR each record retrieved by ParameterSQL LOOP 
30 ~ recursively check visibility 

CheckObjectVisibiUty (LaptopNodeld, CheckDObjName, 
1 newPrimaryRowId, depth + 1, peVisible); 

- Stop as soon as the object is found to be visible! 
IF *peVisible in ('Full', 'Partial') THEN 
35 goto done; 

END IF; 
END LOOP; 

done: 

40 return TRUE; 
} 



45 Dp yraesofVisibilitv 

The docking process may be further enhanced by treating object visibility as 
a non-binary condition; that is, providing for an object to have a degree of visibility 
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SO that it may be visible in certain contexts and not visible in others. This may be 
provided for by associating a visibility strength with each dock object visibility rule. 
Visibility strength is a positive integer that states how visible a given dock object 
instance is. 

5 

Visibility strength provides an alternative to concq)ts of Jully and partially 
visible dock object instances. Rather than specifying visibility as either full or partial, 
visibility strengths allow for an unlimited range of visibility for an object. 

10 When a visibility rule passes, the dock object instance receives the visibility 

strength associated with the visibility rule. This visibility strength controls two 
aspects. 

The first aspect controlled by visibility strength is the downloading or removal 
15 of member table rows. Each member table also has a visibility strength. Docking 
downloads (or removes) member table rows only if the dock object instance visibility 
strength is greater or equal to the member table visibility strength. This aspect may 
be used to limit the number of member table rows rqilicated to docking clients. For 
example, when an Account is visible due to a Quote, docking should download the 
20 Account header, but does not need to download rows in the Account Notes, Account 
Positions, and other member tables. Log Manager download and removal processing 
is improved because Log Manager can skip downloading and removing certain 
member tables. In addition, docking replicates fewer rows to the docking clients, 
and the docking clients occupy less disk space. 

25 

A second aspect controlled by visibility strength is the downloading or removal 
of related dock object instances. Each related dock object rule also has a visibility 
strength. When a dock object instance is visible, docking downloads (or removes) 
related dock object instances only if the dock object instance visibility strength is 
30 greater or equal to the related dock object rule visibility strength. This aspect may be 
used to follow a subsets of related dock objects dq)ending on the reason why the dock 
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object instance is visible. This allows docking to follow a subset of related dock 
objects even if a dock object instance is partially visible. 

Visibility strength is implemented by adding new attributes to the repository 
5 dock object table, dock object visibility rules and dock object related dock object 
rules. These new attributes specify the visibility strengths of member tables, visibility 
rules and related dock object rules. 

Each dock object visibility rule has a visibility strength. When a visibility rule 
10 passes, the dock object instance's visibility strength is equal to the highest visibility 
strength value of all visibility rules that pass. The dock object instance visibility 
strength specifies which member table rows to replicate to a docking client and which 
related dock object rules to run. 

15 Check dock object visibility rules also have a check-dock-object visibility 

strength. The check-dock-object visibility strength value specifies that the current 
dock object instance is visible only if the other dock object instance has a visibility 
strength greater than or equal to the check-dock-object visibility strength value. 

20 Visibility strength is uidicated by an attribute VIS_STRENGTH that specifies 

the strength of the dock object instance. The semantics of this attribute may vary 

depending on the context of the table in which it appears, as more fiiUy discussed 

herein. VIS_STRENGTH may have the following values: 

0: not visible 
25 5: partially visible 

10: fiilly visible 

A number of the tables in the database schema are modified to support the 
30 VIS_STRENGTH attribute. The S_DOCK_TABLE table stores the member tables 
for a docking object. Each docking object can have one or more member tables. The 
table contains an additional field, VIS_STRENGTH. VIS_STRENGTH is a numeric 
field containing the minimum visibility strength of the dock object instance for rows 
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in this table to be downloaded. The field has a default value of 5, indicating that 
member table rows are downloaded if the dock object instance is partially visible. 

The S_DOCK_VIS_RULE table stores the visibility rules for a docking object. 

5 Each docking object can have one or more visibility rules. The table contains an 
additional field, VIS_STRENGTH. VIS_STRENGTH is a numeric field containing 
the visibility strength of the dock object instance if the rule passes. The field has a 
default value of 5 (partially visible) if PARTIAL = 'y', and otherwise is set to 10. 
The S_DOCK_VIS_RULE table also includes a CHECK_VIS_STRENGTH field, 

10 used for check-dock-object rules (i.e., rules with nileType = 'C'). This value 
represents the minimum visibility strength of the check dock object instance to make 
this visibility rule pass. The field has a default value of 10, requiring the check dock 
object to be fully visible, for ruleType='C', and is otherwise unused and set to 0. 

15 The S_DOCK_REL_OBJ table stores the related dock object rules for a 

docking object. Each docking object can have one or more related dock object rules. 
The table contains an additional field, VIS_STEIENGTH. VIS_STRENGTH is a 
numeric field containing the minimum visibility strength of the dock object instance 
for Log Manager to run this rule. It has a default value of 10, requiring full 

20 visibility. The S_DOCK_REL_OBJ table also includes a field 
REL_VIS_STRENGTH. This field contains a value that is used to provide a 
visibility strength value to related dock instances. It has a default value of 5. 

The S_DOCK_INST table is a new table replacing S_DOBJ_INST, and stores 
25 the current visibility strength of a dock object instance for each docking client. It has 
the following fields. NODE_ID is a non-null unique key that indicates the docking 
client corresponding to this row. DOCK_ID is a non-null unique key that indicates 
the dock object corresponding to this dock object instance. PR_TBL_ROW_ID 
contains a key that is the primary table row id of the dock object instance. 
30 VIS_STRENGTH is a numeric field containing the current visibility strength of the 
dock object instance for the docking cMcat. 

The following SQL code may be used to define the S_DOCK_INST table: 
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create table S_DOCK_INST ( 

NODE_ID VARCHAR2(15) NOT NULL, 
POCK_ID VARCHAR2(30) NOT NULL, 
PR_TBL_ROW ID VARCHAR2(15) NOT NULL, 
5 VIS_STRENGTH NUMBER NOT NULL 

); 

create unique index S_D0CK_INST_U1 on S_DOCK_INST 

(NODE_ro, DOCK_ID, PR_TBL_ROW_ID, VIS_STRENGTH); 

10 

The S_DCK_TXN_LOG table stores the transactions to route to docking 
clients. The table contains an additional field, VIS_STRENGTH. VIS_STRENGTH 
15 is a numeric field containing the visibility strength of the table referenced by the 
transaction. This value is denormaiized by the Log Preprocessor and is used by the 
Log Router. It is only used in implementations using the Oracle™ database. The 
following SQL code may be used to define the S_DCK_TXN_LOG table: 

alter table S_DCK_TXN_LOG add (TBL_VIS_STRENGTH NUMBER); 

20 

Lop Manager p rocessing 

Log Manager routes a transaction to a docking client only if the dock object 
25 instance visibility strength is greater or equal to the member table visibility strength. 
The Log Pi^rocessor stores the member table visibility strength as a denormaiized 
value in the transaction log table. 

When Log Router processes visibility events, visibility rules are executed in 
30 decreasing order of visibility strength until a visibility rule passes. When a visibility 
rule passes, the dock object instance receives the visibility strength of the visibility 
rule that passes. If no visibility rule passes, then the dock object instance gets a 
visibility strength of none (value = 0). After calculating the visibility strength, 
visibility strength of the dock object instance is written to the S_DOCK_INST table, 
35 unless the dock object instance has a visibility strength of 0. 
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When Log Router searches for visible transactions, a transactions is fetched 
only if tiie S_DOCK_INST table has a visibility strength that is greater than or equal 
to the visibility strength of the transaction log denormalized member table. 

5 Log Manager uses the member table's visibility strength attribute to identify 

member table rows to download or remove: When the visibility strength of a dock 
object instance changes, Log Manager downloads or removes member table rows for 
the dock object instance. If tiie new visibility strength is greater than the old 
visibility strength, the referenced member table rows have not previously been 

10 downloaded and now should be downloaded. If the new visibility strengtii is less than 
the old visibility strength, then Log Manager removes member table rows that have 
previously been downloaded and should not now be downloaded. 

When processing related dock object rules, Log Manager uses the visibility 
15 strength attribute of each rule to identify which related dock object lules to execute. 
When the visibility strength of a dock object does not change and the visibility 
strength is not None, Log Manager checks related dock object instances and verifies 
that their visibility strength have not changed. When the visibility strength of a dock 
object instance changes, Log Manager checks all related dock object instances and 
20 downloads or removes related dock object instances as needed. If the new visibility 
strength is greater than the old visibility strength. Log Manager executes the related 
dock object rules that have not previously been run and now should be run. If the 
new visibility strength is less than tiie old visibility strength. Log Manager executes 
the related dock object niles that have been previously run and now should not be 
25 run. 

Log Manager uses the relVisStrength attribute of each rule to reduce visibility 
checking. If the new visibility strength is greater tiian or equal to the old visibility 
stiength, and Log Manager finds a related dock object instance and the related dock 
30 object's relVisStrength is greater than or equal to the otiier dock object's maximum 
visibility rule visStrength, then Log Manager does not need to re-check visibility of 
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Other dock object instance. The related dock object instance visStrength is set to the 
related dock object's relVisStrength. 

Simplified Docking Visibility Rules 

5 The utility of the present invention may be made more useful by simplifying 

the docking visibility rules. Specifically, the docking visibility rules may be stored 
in a single location, the central dictionary, so that the database extraction process 
DBXtract and Log Manager can rely on the same definitions to extract and route 
transactions to mobile clients. Predefined docking visibility niles may also be 

10 provided to support commonly required visibility tasks such as position dependencies, 
employee dependencies, and check-dock-object rules. This approach provides several 
benefits. 

First, storing all docking visibility rules in the central dictionary lets both Log 
15 Manager and DBXtract use the same definitions to route transactions to mobile 
clients, reducing the cost of maintaining docking visibility rules. This also eliminates 
the need to maintain DBXtract SQL scripts for each different database vendor (e.g. 
Sybase™, Oracle™, or Informix™). Second, it permits the definition of pre-defined 
visibility rules commonly used by vendor-supplied applications. These rules make 
20 it unnecessary to enter SQL fragments or define related docking object rules. 90% 
of all docking visibility rules for typical applications may use pre-defined visibility 
rules. Third, the central dictionary lets customers use the Docking Object List view 
to easily customize docking visibility rules to satisfy site-specific requirements. 
Customers can also easily activate or deactivate visibility rules by changing an 
25 attribute of a visibility nile. With simplified visibility rules, clients, such as end 
users, can change visibility rules using an easy-to-use graphical user interface. This 
improves performance for majority of customers by letting us define specialized 
visibility rules for a small set of customers as inactive rules and letting the customers 
activate the specialized rules. Customers that do not use the specialized rules do not 
30 incur the performance cost of the specialized rules. Fourth, storing all docking 
visibility rales in a unified location makes it easier to build future docking 
enhancements. 
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Simplified docking rules are implemented as follows. Five new types of 
visibility rules are defined and stored in the central dictionary. 

1) Check-dock-object rules relate two docking object instance to each other 
without the use of a SQL fragment. Check dock object rules are similar to SQL rules 

5 except that a check dock object defmition between two docking objects is stored 
instead of a SQL fragment. For example, an opportunity is visible if an activity that 
is fully visible uses the opportunity. 

2) Position rules specify that a docking object instance is visible if an 
employee on the docking client occupies a position for the docking object. For 

10 example, an opportunity is visible if an employee on the docking client is an 
opportunity sales team member. 

3) Position manager rules specify that the docking object instance is visible if 
an employee on the docking client is the manager of an employee that occupies a 
position for the docking object. For example, an opportunity is visible if an employee 

15 on the docking client is the manager of an opportunity sales team member. 

4) Bnployee niles specify that a docking object instance is visible if an 
employee on the docking client is assigned to the docking object. For example, an 
activity is visible if an employee on the docking client is assigned to the activity. 
Employee rules are typically used for owner, creator, etc. 

20 5) Employee manager rules specif that the docking object instance is visible 

if an employee on the docking client is the manager of an employee assigned to the 
docking object. For example, an activity is visible if an employee on the docking 
client is the manager of an employee assigned to the activity. Employee manager 
niles are typically used for manager of owner, manager of creator, etc. 

25 

In Log Manager, visibility SQL statements are generated from the central 
dictionary at runtime. Code is added to the visibility checker common API to 
generate and run SQL statements for the new visibility rule types. Log Manager's 
visibility event code is modified to use the new types of visibility rules to find related 
30 docking object instances. 
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Fig. 9 depicts a database diagram for the central dictionary. This diagram is 
akin to the schema of Fig. 2 with additional support added to the 
S_DOCK_VIS_RULE table, as foUows. 

5 The S_DOCK_VIS_RULE table contains the visibility rules associated with 

a particular Docking Object. S_DOCK_VIS_RULE 71 contains the additional fields 
DOCK_ID, SEQUENCE, TYPE, ACTIVE and PARTIAL. Field DOCK_ID 
identifies the Docking Object with which a particular visibility rule is associated, 
referred to as the "current docking object. " Field SEQUENCE is a sequence number 
10 that indicates the sequence, relative to other visibility rules in the table, in which the 
particular visibility rule should be run. The ACTIVE field indicates whether a 
particular rule is active or not. A value of 'Y' or null indicates that the rule is active, 
and a value of 'N' indicates that it is inactive. The field TYPE specifies the type of 
the particular visibility rule. A value of 'S' indicates an SQL rule; a value 'O' 
1 5 indicates a parameter dock object rule; a value 'C indicates a check-dock-object rule; 
a value 'P' indicates a position rule; a value 'Q' indicates a position manager rule; 
a value 'E' indicates an employee rule; a value 'F' indicates an employee manager 
rule. The field PARTIAL, if set to 'Y', indicates that if the visibility rule is 
satisfied, the current docking object is partially visible. If set to 'N' or null, it 
20 indicates that if the visibility rule is satisfied, the current docking object instance is 
fully visible. 

In addition the S_DOCK_VIS_RULE table contains a number of fields whose 
meaning and meaningfiihiess depends upon the rule type. 

25 

SQL niles use the fields SQL_STATEMENT and VIS_EVT_COLS. In this 
context, the SQL_STATMENT field is an SQL fragment that, if it returns any rows, 
indicates that the dock object instance is visible. 

30 Parameter Dock Object Rules use the fields CHECK_DOCK_ID and 

SQL_STATMENT. In this context, CHECK_DOCK_ID contains a pointer to another 
docking object and SQL_STATEMENT contains an SQL statement to obtain the 
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PrimarylD values for the other dock object. For each PrimarylD retrieved, Log 
Manager nins the visibility rule of the other dock object. 

Check-Dock-Object rules use the fields CHECK_DOCK_ID, 
5 SRC_COLUMN_ID and TAR_COLUMN_ID. In this context, SRC_COLUMN_ID 
identifies the column in the current dock object that joins to the check dock object and 
TAR_COLUMN_ID identifies the column in the check dock object that joins to the 
dock object join column. For the Check-Dock-Object type, the visibility event 
columns is implicit: all columns needed to join from the primary table of the current 
10 dock object to the dock object join column. 

Position rules use the field POSTN_COLUMN_ID, which is a column in a 
member of table of the current dock object that points to the S POSTN table. For 
Position rules, the visibility event columns is implicit: all columns needed to join 
15 from the primary table of the current dock object to the position column. 

Position Manager rules use the field POSTN_COLUMN_ID, which is a 
column in a member of table of the current dock object that points to the S_POSTN 
table. For Position Manager rules, the visibility event columns is implicit: all columns 
20 needed to join from the primary table of the current dock object to the position 
colunm. 

Employee rules use the field EMP_COLUMN_ID to identify a column in a 
member table of the current dock object that points to the S_EMPLOYEE table. For 
25 &nployee rules, the visibility event colunms are implicit: all columns needed to join 
from the primary table of the current dock object to the employee column. 

Employee Manager rules use the field EMP_COLUMN_ID to identify a 
column in a member table of the current dock object that points to the S_POSTN 
30 table. For ^nployee Manager rules, the visibility event colunms is implicit: all 
colunms needed to join fiom the primary table of the current dock object to the 
employee column. 
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SQL statements are stored in the central dictionary memory structures for 
access by Log Manager and DBXtract. When the dictionary is loaded, SQL 
statements are generated and stored in the memory structures. Because the number 
of SQL statements are small, the generation code is expected to take less than one 
5 second. Alternatively, if the generation takes too long, the dictionary API may be 
modified to generate the SQL statements for a given dock object whenever the dock 
object is first referenced. 

Appendix B describes the format SQL statements that Log Manager and 
10 DBXtract generate at runtime and provide an example of these SQL statements using 
the Accounts dock object. 

CONCLUSION 

Various modifications to these embodiments wiU be readily apparent to 
15 those skilled in the art, and the generic principles defmed herein may be ^plied to 
other embodiments without the use of inventive faculty. Thus, the present 
invention is not intended to be limited to the embodiments shown herein, but is to 
be accorded the widest scope consistent with the principles and novel features 
disclosed herein. 

20 All publications and patent applications mentioned in this specification are 

herein incorporated by reference to the same extent as if each individual 
publication or patent application was specifically and individually indicated to be 
incorporated by reference. 

The invention now being fully described, it will be apparent to one of 
25 ordinary skill in the art that many changes and modifications can be made thereto 
without departing therefrom. 
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APPENDIX A 

Writing User Transactio n Log File fo r a Given Laptop Node 

This program will be called by a server-side process that processes transaction log 
entries for all Laptop Nodes. For each Laptop Node, the calling process building the 
UserTrxnLogFileName and calling Program 1. 

Input Parameters 

• LaptopNodeld - nodejd of the destination laptop 

• UserTxnLogFileName - full path of the file where txns will be written 

• MaxBatchTxns - number of txns between commits and updates to the 
S_DOCK_STATUS table 

• MaxTxns - number of txns to process in this session. Use this parameter to 
limit processing. 

Main Algorithm 

-- Check parameters 

IF (MaxTxns < 1 I I MaxBatchTxns < l) THEN 

Invalid Parameter 
END IF 

-- Get last IjOG_EXTIIACT number for the Laptop from S_DOCK_STATOS 
last_txn_commit_nuinber = OTLDStatGetLogNvun (LaptopNodeld) ; 

-- Initialize Variables 

NumTxns « 0; Total number of txns processed 

NumBatchTxns = 0; - - Total number of txns written in the current 
batch 

-- Read Docking Object and Table definitions into memory structures 
StartDictJ^i () ; 

-- Open the User Ijog Txn file 
Open User Log Txn file 

-- Select and process new txns in S_D0CK_TRANSACT10N_L0G 
-- where txn_commit_number > las t_txn_commi t_number 
FOR each new txn LOOP ~ 

-- Stop processing if reach MaxTxns 
IF NumTxns = M£ocTxns THEN 

break ; 
END IF; 

- - Prevent circular txns . Do not send the txn back to the 
originating leiptop 

IF txn.OriginNodeld = LaptopNodeld THEN 

Goto next transaction 
END IF; 

Process all other types of trcmsactions 
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This is the visibility calculator 1 
-- This routine also processes implicit visibility events 
-- Later: Data Merge can call this function to check iirtiether a txn 

is 

still visible when merging txns into a laptop or server 
database . 

CheckVisibility (LaptopNodeld, LogRecordType , TableName, 
TransRowld) ; 

IP txn is visible THEN 

-- Write transactions to OserTxnLog file depending on the 

-- type of LogRecordType. 

Write the txn to the user log file 

-t-t-NumBatchTxns 
END IF; 

Finished processing the txn 

-- Conmit (if needed) 

IF NumBatchTxns = MaxBatchTxns THEN 

-- Assume that separate process comes around and deletes 

-- Txns in 3_D0CK_TRANSACTI0N_L03 that have been procesBed 

-- for all nodes. So, no need to delete the txns from the log. 

Update last LOG_EXTRACT number for Laptop in S_DOCK_STATDS 

CoDBnit; 

NumBatchTxns = 0 
END IF; 



-- Commit 

Update last IiOG_EXTRACT number for Laptop in S_DOCK_STATDS 



-- Close log file (if needed) 
IF UserTxnLogFileP != NULL THEN 

Close File; 
END IF; 

StopDictApi {) ; 

Check Visibility Routines 

-- Check if a record in the txn log is visible to a LaptopNodeld 
BOOL CheckVisibility (LaptopNodeld, LogRecordType, TableName, 
TransRowld) 

-- SQLStatements routed based on the destination list 
IF LogRecordType in ( ' SQLStatement ' ) THEN 

IF Laptop Node in destination list THEN 
return TRUE; 

END IF; 

-- Shadow and Multi Record LogRecordTypes are routed to all nodes 
-- No visibility events with these LogRecordTypes. 
ELSIF LogRecordType in ('ShadowOperation' , 'MultiRecordDelete' , 
'MultiRecordUpdate' ) THEN 

return TRUE; 

-- Single Deletes need more processing 

ELSIF LogRecordType in ('Sin^ile Delete') THEN 

IF (table. visibility in ('Enterprise', 'Limited')) THEN 
return TSDB; 

END IF; 
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-- Sintple Inserts suid Siotple Updates need more processing 
-- CheckTsmVisibility 0 also processes in5>licit visibility events 
EIiSIF LogRecordType in ('SiiiQ>le Insert', 'Sin^jle Update') THEN 
IP (table .visibility = 'Enterprise') THEN 
5 return TKUE; 

ELSIF tedjle. visibility = 'Limited' THEN 

IF CheckTxnVisibility (LaptopNodeld, Table, Rowld) THEN 

return TRDE; 
END IF; 
10 END IF; 

END IF; 

} 

-- Check if a record in the txn log is visible to a LaptopNodeld 
15 static BOOL CheckTxnVisibility (LaptopNodeld, Table, Rowld) 

BOOL bVisible = FALSE; 

Find the Table in the Dictioneury; 
20 IF Table not found THEN 

Error: Table not defined 
END IF; 

FOR all docking objects that the table belongs to LOOP 
25 -- Generate SQL to get Primaryld values of the Docking Object 

GeneratePrimaryldSQL (Table, Rowld, DockingObject) ; 
FOR each Primaryld value retrieved LOOP 

CheckObjectvisibility (LaptopNodeld, PrimaryTable , 
PrimaryRowId) 
30 IF object is visible THEN 

-- Because CheckObjectvisibility () also processes implicit 
visibility events, we must loop through ALL docking 

objects 

-- even if we already know that the Txn is visible. 
35 -- Exception: if the table has VIS_event_FLG = 'N' 

then we can return immediately. 
IF Table. visibilityEventFLG = 'N' THEN 

return TRUE; 
ELSE 

40 bVisible = TRDE; 

END IF; 
END IF; 
END LOOP; 
END LOOP; 

45 

return bVisible; 

} 



50 -- Check if an instance of a docking object is visible to the laptop 
user. 

-- Also processes in^jlicit visibility events 1 
BOOL CheckObjectvisibility (LaptopNodeld, DockingOb j ectName , 
PrimaryRowId) 
55 { 

FOR each visibility rule for the Docking Object LOOP 
IF RuleType = RuleSQL THEN 

Run the select SQL statement using PrimaryRowId; 
IF any rows returned THEN 
60 row is visible 

-- Process an iii?>licit Download Object 
DownloadObjectlnstance (LaptopNodeld, PrimaryTableName , 

PrimaryRowId) ; 

return TRDE; 
65 END IP; 

ELSIP RuleType = ChecJiDockingObject THEN 

Run the ParameterSQL using PrimcuryRowId to get newPrimaryRowId 
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FOR each record retrieved by ParameterSQL LOOP 
-- RECURSIVE! 

CheckObjectVisibility (LaptopNodeld, CheckDockxngObj ectName , 
newPrimaryRowId) ; 

5 IP rc = TRDE THEN 

-- Process an in^jlicit Download Object 
DownloadObjectlnstance (LaptopNodeld, PrimaryTableName, 
PrimaryRowId) ; 

return TRUE; 
10 END IF; 

END LOOP; 
END IP; 
END LOOP; 

15 -- Object is not visible. 

-- Process an in^jlicit Remove Object 
RemoveObjectlnstance (LaptopNodeld, PrimaryTableName, 
PrimaryRowId) ; 

20 

return FALSE; 

} 



Generate SQL Statement to Get Primaryld 

25 

-- Generate the SELECT SQL statement to get the Primaryld value of 
-- the docking object for the given MemberTable 

-- SQL statement looks like: 
30 -- SELECT tp.<row_id> 

FROM <table_owner> .<Table> tl, 

<table_owner>.<PKTable> t2, 

... one or more intermediate tables between the table 
and the PrimaryTable 
35 .. <table_owner> . <PKTable> tN 

<table_owner> . <PrimaryTable> tp 
WHERE tl.ROW_ID = :row_id /* row_id in transaction log */ 
/* join to PK table t2 */ 
AND tl . <FKColumn> = t2 . <PKColumn> 
40 AND <tl FKCondition> 

/* any number of joins until reach the teible that joins 

to the PrimaryTable */ 
/* join from t2 to tN */ 
AND t2 . <FKColumn> = tN . <PKColumn> 
45 -- AND <t2 FKCondition> 

/* join to the PrimaryTable */ 
AND tN.<FKColumn> = tp . <PKColumn> 
AND <tN PKCondition> 

50 -- Note that there may be one or more paths from the Member Table 

-- to the Primary TzLble. We need to generate a SQL select statement 
- - for each of the paths and UNION the statements together . 

-- This function assumes that there are no loops in the definition. 

-- These SQL statement do not change for each Table in a Docking 
Object, 

-- so we cem calculate them one and store them xn memory. 
60 struct 

CHAR* selectList; 
CHAR* fromClause; 
CHAR* whereClause; 
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OINT numTcLbles; /* also the number of joint to reach the Primary 
Table */ 
} GenStmt; 

GeneratePrimaryldSQL (Table, DockingObject) 

/♦ there may be more than one SQL statement, so we have a dynamic 
array o£ SQL statements. Each element in the array is a path 
from the TeOsle to the Primary Table*/ 

DynArrld GenStmtArr; 

GenStmt newGenStmt; 

CHftR* sqlStmt; 

DynArrCreate (GenStmtArr) ; 

Create the first element and initialize 
newGenStmt = mallocO; 
newGenStmt.numTables ■ 1; 
newGenStmt . selectList = "SELECT row_id" ; 
newGenStmt . f romClause = "FROM <Table> tl"; 
newQenStmt . whereClause = "WHERE tl.ROW_ID = :row_id"; 
DynArrAppend (GenStmtArr, &newGenStmt) ,- 

/* Recursively follow FKs to the PrimaryTable */ 

Build the select, from cmd ^rtaere clause simultaneously */ 
AddPKTable (Table, DockingObject, GenStmtArr, 0) ; 

-- Union all the paths together 
numStmts = DynArrSize (GenStmtArr) ; 
FOR all elements in the array LOOP 

tit?)SglStmt = GenStmtArr [j] .selectList I I GenStmtArr [j] .f romClause 
1 1 GenStmtArr [ j ] .whereClause ; 

sglStmt = sqlStmt | | 'UNION' | | tn^SglStmt; 
END LOOP; 



DynArrDestroy (GenStmtArr) ,- 

IF sqlStmt = NUliL THEN 

Error: no path from Table to Primary Table. 
END IF; 



-- Recursively follow all FKs to the Primary Table 
AddPKTeible (Table, DockingObject, GenStmt, InputStmtNum) 
{ 

UINT nximFKS 3 0; 
niNT StmtNian; 
GenStmt newGenStmt ; 

FOR all FKs for the table LOOP 

IF PKTable is a Member Table of the Docking Object THEN 

-- If there's more than one FK, then there is more than one 

path 

-- out of the current table. 

-- Copy the SQ L st mt to a new DynArrElmt to create a new path 
IF numFKs > 0 THEN 

- - Create a new element and copy from GenStmt [InputStmtNum] 

newGenStmt = mallocO; 

newGenStmt.nimirables = GenStmt [InputStmtNum] .numTables; 
newGenStmt . selectList = GenStmt [InputStmtNum] . selectList ,- 
newGenStmt . fromClause = GenStmt [InputStmtNum] .f romClause; 
newGenStmt . whereClause s GenStmt [Iz^utStmtNum] . whereClause ; 
DynArri^end ((SenStmtArr, &newGenStmt) ; 
StmtNum = DynArrSize (GenStmtArr) ; 



-55- 



Copied from 09967400 on 12/14/2005 



wo 98/38583 



PCT/US98/03573 



l>" , 



-- Put a check here for infinite loops 
IF StmtNum ==20 THEN 

Error: Probably got an Infinite loop? 
END IF; 
ELSE 

StmtNvun = InputStmtNum; 
END IF; 

-- impend the new PKTable to the fromClause and whereClause 
GenStmt [StmtNtim] .fromClause = 

GenStmt [StrntUum] . fromClause || ",\n <Table> t<numTables ■ 

GenStmt [StmtNum] .whereClause = 

GenStmt [StmtNvun] .whereclause || 
"J^ND t<numTableB> . <FKColumn> = t<numTablBS + 
l>.<PKColumn>'' || 

"AND <FKCondition for Table if 2uiy>"; 
++GenStmt . numTables ; 

-- PKTable is the Primary Table then Done. 
IF PKTable = PrimaryTable THEN 

RETURN; 
ELSE 

AddPKTable (PKTable, DockingObject, GenStmt, StmtNum) ; 
END IF; 

Only count FKs to other member tables in the same Docking 

Object 

++numPKs ; 



RETDHN; 

35 } 

Process Visibility Events 

-- Download an Object Instance to a Laptop 

-- This function also downloads all Related Docking Object instances. 
40 BOOL DownloadObjectlnstance (LaptopNodeld, ObjectName, PrimaryRowId) 

^ -- Check if the object instance is already downloaded to the laptop 
Find the object instance in the S_DOBJ_INST tJible 
IF exists on laptop THEN 
45 return TRUE; 

END IF; 

-- Register object instance in S_DOBJ_INST table 

50 -- Write Download Object records to the Txn Log 

FOR each member table of the docking object LOOP 
Generate SQL select statement to download records 
Write each retrieved record to the User Txn Log file 
END LOOP; 

55 

-- Download records for Parent Object instances 
FOR each RelatedDockingObject LOOP 

Run ParameterSQL to get newPrimsuTrld of RelatedDockingObjects 
FOR each newPrimsu^rld retrieved LOOP 
60 -- Check if the instance of the object is visible to the laptop 

^^^^ CheckObjectVisibility (LaptopNodeld, ObjectName, PrimaryRowId) 
IF visible THEN 

DownloadObj ectlnstance (LaptopNodeld, 
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RelatedDockingOb j ect , 

newPrimaryRowId) ; 
END IF; 
END LOOP; 
5 END LOOP; 

return TPUE; 

} 

10 

-- Remove an Object Instance to a Laptop 

-- This function also removes all Related Docking Object instances. 
BOOL RemoveObj ect Instance (LaptopNodeld, ObjectName, PrimaryRowId) 

15 ^ -- Check if the object instance is already downloaded to the laptop 
Find the object instance in the S_D0BJ_1NST table 
IF does not exist on laptop THEN 

return TRUE; 
END IF; 

20 

-- Delete the object instance frcan S_DOBJ_INST table 

-- Write Remove Object records to the Txn Log 
FOR each member table of the docking object LOOP 
25 Generate SQL select statement to get records to delete 

Write each retrieved record to the User Txn Log file 
END LOOP; 

-- Remove for Parent Object instances 
30 FOR each RelatedDockingObject LOOP 

Run ParameterSQL to get newPrimaryld of RelatedDockingOb jects 
FOR each newPrimaryld retrieved LOOP 

-- Check if the instance of the object is visible to the laptop 

user 

35 CheokObjectVisibility (LaptopNodeld, ObjectName, PrimaryRowId) 

IF not visible THEN 

RemoveObj ectlnstance ( LaptopNodeld , 

RelatedDockingObject, newPrimaryRowId) ; 

END IF; 
40 END LOOP; 

END LOOP; 



45 



return TRUE; 

} 
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Appendix B: SQL Statements and Examples 



Top Level SQL Statements 

This section describes the format SQL statements that Log Manager and DBXtract generates at 
runtime. See the next section for an example of these SQL statements using the Accounts dock 
5 object. 

Log Manager Visibility SQL Statements 

Log Manager generates visibility sql statements when checking the visibility of a dock object 
mstance. Log Manager generates a <sub sql statement > for each visibility rule, the structure of 
which depends on the visibility rule type (see Sub SQL Statements below). 



20 Log l\/lanager Related Dock Object SQL Statements 

Log Manager generates related dock object sql statements after the visibility of a dock object 
instance has changed. Log Manager generates one or more <sub sql statements > for each 
visibility rule, the structure of which depends on the visibility rule type (see Sub SQL Statements 
below). 



10 



select 
from 
where 
and 



'X' 

S:Table_Owner.<priitiary table> primary_table 
priinary_table.ROW_ID = <primary_row_id> 
( (<stib sql statement > 1) 
OR (<sub sql statement 2>) 



15 



OR (<s\ib sql statement N>) 



/ 



25 



<sub sql statement> 
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Sub-Statements for SQL Rules 



Log Manager Visibility SQL Statements 

<sql fragment > 

S Ijog n^anager Related Dock Object SQL Statements 

User enters related dock object sql statements. 

DBXtract Phase 2 SQL Statements 

select DISTINCT pt.ROW_ID ITEM_ID_T, <dobj_id> 
ITEM_TYPE_T, 

:node_id CREATED_BY_T, .cpartial flag> 
PARTIAL_FLG_T 

from : table_ovnier.<primary_table> pt 
where <sql fragment> 
and pt.ROW_ID not in 

(select di.ITEM_ID 

from :table_ovmer.S_DCK_INIT_ITEM di 
where di . CREATED_BY = :node_id 
and di.ITEM_TYPE = <dobj_id>) 

/ 



15 
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Sub-Statements for Check Dock Object Rules 
Log Manager Visibility SQL Statements 

SQL Statement Template 

5 exists (select 'C 

from STables 

&Table_Ovmer.S_DOBJ_INST di 
where di.NODE_ID = :node_id 

and di.DOBJ_ID = &Check_DObj_Id 
10 and di.STAT_FLG = 'F' 

and di . PR_TBL_ROW_ID = &Join_Column 
&Joins 



Algoritbin 

Build source and target dock object paths separately. Join source path to source primary table. 
Join target path to S DOBJJNST table. Then join source and target using the two join columns. 

Build Source object paths 

IF source join column table = source primary table 
THEN 

can optimize: join target object directly to 
primary table 

&Tables: add nothing 
&Joins : add nothing 

pSrcJoinCol = "primary_table . <source join col\imn>" 
ELSE 

Get paths from source join column table to source 
primary table. 

- The paths will not include the source primary table 

- The paths will not include the source join column 
&Tables: Add every table in path to from clause, last 

Pi foment first: 

" &Table_Owner . <pathcol [N] - >pTable - >pTableName> 

sN" 

&Joins : 

- JVdd joins for all path cols except the last 
element : 

"and sN.<pathcol [N] ->pColvimnName> = sN+l.ROW_ID" 

- Add join from last element to primary rowid: 

"and s<last>.<pathcol [last] ->pColumnName> = 
primary_table . ROW_ID" 

pSrcJoinCol = "sl.<source join column>" 
END IF 

1. Build Target object paths 

IF target join coliann = target primary table ROW_ID 
THEN 

-- can optimize: join source object directly to 
S_DOBJ_INST table 

SeTables: add nothing 
&Joins : add nothing 
pTarJoinColumn: nothing 
&Join_Column: pSrcJoinColumn 
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Get paths from target join column table to target 
primary table. 

- The path will not include the target primary table 
5 if the path traverses 

any other member table. 

- The paths will not include the target join column. 
STables: Add every table in path, first element first 

n &Tables_Owner . <pathcol [N] - >pTable- >pTableName> 

10 tN" 

foJoins : 

- Add joins for all path cols except the last 
element : 

"and tN+l.ROW_ID = tN.pathcol [N] ->pCol\imnName" 
15 (note backwards order) 

pTar JoinColumn : ''tl.<Target join column>" 
SaJoin_Coliimn : "t<last>. <pathcol [last] - >pColumnName>" 



2. Join source and target join columns 

SbJoins : Add join from target join colximn to source 
join colxamn if both exist: 

"and <pTarJoinColumn> = <pSrcJoinColumn>" 

3. Replace &Tables, &Join_Column and &Joins in the SQL 
statement template. 

Example 1: Opportunity visible due to ActiTlty 

Source Object = Opportunity (src ptable: S_OPTY) 

Target Object = Activity (tar ptable: S_EVT_A(?r) 

Source join column = S_OPTY . ROW_ID 

Target join coliimn = S_EVT_ACT . OPTy_ID 

1. Target Path: S_EVT_ACT . ROW_ID 
&Tables: S_EVT_ACT tl 

ScJoins : and di . PR_TBL_ROW_ID = ti.ROW_ID 
pTarJoinCol: tl.OPTY_ID 

2. Source Path: S_OPTy . ROW_ID 
&Tables: add nothing 
&Joins : add nothing 

pSrc JoinCol : primary_table . ROW_ID 

3 . Join source and target 

SiJoins : and tl.OPTY_ID = primary_table.ROW_ID 

select 'X' 

from &Table_Owner.S_OPTY primary_table 
where ROW_ID = ? 

cuid exists (select 'C 

from &Table_Owner.S_EVT_ACT tl, 
&Table_Owner . S_DOB J_INST di 
where di.NODE_ID = :node_id 

and di.DOBJ_ID = &Check_DObj_Id 

and di.STAT_FLG = 'F' 

and di.PR_TBL_ROW_ID = tl.ROW_ID 
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and tl.OPTY_ID = 
primary_table . ROW_ID) 

Example 2: Activity visible due to Opportunity 

5 

Source Object = Activity (src ptable: S_EVT_ACT) 

Target Object = Opportunity (tar ptable: S_OPTY) 
Source join column = S_EVT_ACT . OPTY_ID 
Target join colimin = S_OPTY . ROW_ID 



10 



1. Target Path: S_OPTy . R0W_ID 
ScTables: S_OPTY tl 

SbJoins : add nothing 
pTaraJoinCol : di . PR_TBL_ROW_ID 

2. Source Path: S_EVT_ACT . ROW_ID 
ScTables: add nothing 

& Jo ins : add nothing 

pSrc JoinCol : primary_table . OPTY_ID 

3 . Join source and target 
&Joins: and di . PR_TBL_ROW_ID = 
priiaary_table . OPTY_ID 

select 'X' 

from &Table_Ovmer.S_EVT_ACT prima3:y_table 
where ROW_ID = ? 

and exists (select 'C 

from &Table_Owner.S_OPTY tl, 

&Table_Owner.S_DOBJ_INST di 
where di.NODE_ID = :node_id 

and di.DOBJ_ID = &Check_DObj_Id 
and di.STAT_FLG = 'F' ~ 
and di . PR_TBL_ROW_ID = 
primary_table . OPTY_ID) 
/ 

Example 3: Account visible due to Partner Account 

Source Object: Account (src ptable: S_ORG_EXT) 
Target Object: Account (tar ptable: S_ORG_EXT) 
Src join column: S_ORG_EXT . ROW_ID 
Tar join colijmn: S_ORG_REL . PRTNR_OU_ID 

1. Target Path: S_ORG_REL . OU_ID 
&Tables: S_ORG_REL tl 

&Joins: and di . PR_TBL_ROW_ID = tl.OU_ID 
pTar JoinCol : t 1 . PRTNR_OU_ID 

2. Source Path: S_ORG_EXT . ROW_ID 
STables: add nothing 

&Joins : add nothing 

pSrc JoinCol : primary_table . ROW_ID 

3 . Join source and target 

&Joins: and tl.PRTNR_OU_ID = primary_table.ROW_lD 

exists (select 'C 

from &Table_Owner.S_ORG_REL tl, 
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&Tabl e_Owner . S_DOB J_INST di 
where di.NODE_ID = :node_id 

and di.DOBJ_ID = &Check_DObj_Id 
and di.STAT_FLG = 'F' 
and di . PR_TBL_ROW_ID = tl.OU_ID 
and tl . PRTNR_OU_ID = 
priinary_table . ROW_ID) 
/ 

Example 4: Account visible due to I^rait Account 

Source Object: Account (src ptable: S_ORG_EXT) 
Target Object: Account (tar ptable: S_ORG_EXT) 
Src join column: S_ORG_EXT . ROW_ID 
Tar join column: S_ORG_EXT . PARENT_OU_ID 

1. Target Path: S_ORG_EXT . ROW_ID 
&Tables: S_ORG_EXT tl 

StJoins : and di . PR_TBL_ROW_ID = tl.ROW_ID 
pTar JoinCol : t 1 . PARENT_OU_ID 

2. Source Path: S_ORG_EXT . ROW_ID 
&Tables: add nothing 

ScJoins : add nothing 

pSrc JoinCol : primary_table . ROW_ID 

3. Join source and target 

&Joins: and tl . PARENT_OU_ID = primary_table.ROW_ID 

exists (select 'C 

from &Table_Owner.S_ORG_EXT tl, 
&Table_Ovmer . S_DOBJ_INST di 
where di.NODE_ID = :node_id 

and di.DOBJ_ID = &Check_DObj_Id 
and di.STAT_FLG = 'F' 
and di . PR_TBL_ROW_ID = tl.ROW_ID 
and tl.PARENT_OU_ID = 
primary_table . ROW_ID ) 
/ 



3 . Log Manager Related Dock Object SQL Statements 
SQL Statement Tonplate 

select pt.ROW_ID 
from &Tables 
ScJoins 

/ 

Algorithm 

Build source and tais^t dock object padis separately. Join target path to :primaiy_row_id. 
Join source and target using the two join columns. Get source primary table ROW_IDl 

1. Build Target object paths 

IF target join column = target primary table ROW_ID 
THEN 
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-- can optimize: join source object directly to 
: pr iinary_row_id 

&TcQ3les: add nothing 

&Joins : add nothing 

pTarJoinColumn = " :primary_row_id'' 
ELSE 

Get paths from target join column table to target 
primary table. 

- The paths will not include the target primary table 
if the path traverses 

any other member table. 

- The paths will not include the target join column. 
&Tables: Add every table in path last element first 

_ " &Table_Owner . <pathcol [N] - >pTable - >pTableName> tN" 

&Joins : 

- Add join from : pr imary_row_id to last path 
column: 

"and t<last>.<pathcol [0] ->pColumnName> = 
: pr imary_row_id " 

- Add joins for all path cols except the last 
element : 

"and tN+l.ROW_ID = tN.<pathcol [N] - 
>pColiimnName>" (note backwards order) 

pTar JoinColiimn : "tl.<Target join column>" 
END IF 

Build Source object paths 
Always add source primary table in join to guarantee 
that the source dock object instance exists 
IF source join column table = source primary table 
THEN 

-- optimize: can omit source tables from SQL 
statement 

&Tables: "<source primary table> pt" 
&Joins : add nothing 
pSrcJoinCol: "pt.<src join col\amn>" 
ELSE 

Get paths from source join coliamn table to source 
primary table. 

- The paths will not include the source primary table 

- The paths will not include the source join column 
&Tables : 

- Add every table in path to from clause, first 
element first: 

" &Table_Owner . <pathcol [N] - >pTable- 
>pTableName> sN" 

- Add source primary table to from clause: 

"&Tcible_Owner .<source primary table> pt" 

& Jo ins 

- Add joins for all path cols except the last 
element : 

"and sN.<pathcol [N] ->pColumnName> = 
sN+l.ROW_ID" 

- Add join from last element to source primary table 
row id: 
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"and s<last>.pathcol [last] ->pCol\unnName = 

pt.ROW_ID° 

pSrcJoinCol = ''sl.<Source join coluinn>" 
END IF 

3. Join source and target join columns 

&Joins: Add join from target join colxamn to source join 
column: 

"and <pTarJoinCol> = <pSrcJoinCol>" 

Example 1: Opty visible due to Activity (Get all Opportunities for an Activity) 

Source Object = Opportunity (src ptable: S_OPTY) 
Target Object = Activity (tar ptable: S_EVT_ACT) 
Source join column = S_OPTY . ROW_ID 
Target join colxamn = S_EVT_ACT . OPTY_ID 

1. Source Path: S_OPTY . ROW_ID 
&Tables: S_OPTY pt 

&Joins : add nothing 
pSrcJoinCol: pt.OPTY_ID 

2. Target Path: S_EVT_ACT . ROW_ID 
&Tables: S_EVT_ACT tl 

&Joins : cuad :primary_row_id = tl.ROW_ID 
pTar JoinCol : tl . OPTy_ID 

3. Join source and target 

&Joins : and tl.OPTY_ID = pt.ROW_ID 

select pt.ROW_ID 

from &Table_Owner.S_EVT_ACT tl, 
&Table_Owner.S_OPTY pt 
where : pr imary_row_id = tl.ROW_ID 
and tl.OPTY_lD = pt.ROW ID 

/ 

Example 2: Activity visible due to Opportunity (Get all Activities for an Opportunity) 

Source Object = Activity (src ptable: S_EVT_ACT) 

Target Object = Opportunity (tar ptable: S_OPTY) 
Source join column = S_EVT_ACT . OPTY_ID 
Target join column = S_OPTY . R0W_ID 

1. Source Path: S_EVT_ACT . ROW_ID 
&TcLbles: S_EVT_ACT pt 

SaToins : add nothing 
pSrcJoinCol: pt.OPTY_ID 

2. Target Path: S_OPTY . ROW_ID 
&Tables: add nothing 
&Joins : add nothing 

pTar JoinCol: : primary_row_id 

3 . Join source ajid target 

&Joins : and tl.OPTY_ID = pt.ROW_ID 

select pt.ROW_ID 

from &Table_Ovmer.S_EVT_ACT pt 
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where : priniary_row_id = pt.OPTY_ID 

/ 

Example 3: Account visible due to Partner Account (Get all Accounts for a partner Account) 

5 

Source Object: Account (src ptable: S_ORG_EXT) 
Target Object: Account (tar ptable: S_ORG_EXT) 
Src join column: S_ORG_EXT . ROW_ID 
Tar join column: S_ORG_REL . PRTNR_OU_ID 

10 

1. Source Path: S_ORG_EXT . ROW_ID 
&Tables: S_ORG_EXT pt 
&Joins : add nothing 
pSrcJoinCol : pt . ROW_ID 
15 2. Target Path: S_ORG_REL . OU_ID 

STables: S_ORG_REL tl 

&Joins : and : pr imary_row_id = ti.OU_ID 
pTar JoinCol : 1 1 . PRTNR__OU_ID 
3 . Join source and target 
20 &Joins : and tl . PRTNR_OU_ID = pt.ROW_ID 

select pt.ROW_ID 

from &Table_Ovmer . S_ORG_REL tl, 
&Table_Owner.S_ORG_EXT pt 
25 where : pr imary_row_id = tl.OU_ID 

and tl.PRTNR_OU_ID = pt.ROW_ID 

/ 

Example 4: Account visible due to Parent Account (Get all Accounts for a Parent Account) 

30 

Source Object: Account (src ptable: S_ORG_EXT) 
Target Object: Account (tar ptable: S_ORG_EXT) 
Src join column: S_ORG_EXT . ROW_ID 
Tar join colvimn: S_ORG_EXT . PARENT_OU_ID 



35 



1. Source Path: S_ORG_EXT . ROW_ID 
&Tables: S_ORG_EXT pt 

& Jo ins : add nothing 
pSrc JoinCol: pt.ROW_ID 

2. Target Path: S_ORG_EXT . ROW_ID 
ficTables: S_ORG_EXT tl 

&Joins : and :primary_row_id = tl.ROW_ID 
pTarJoinCol : tl . PARENT_OU_ID 

3 . Join source and target 

&Joins: and tl . PARENT_OU_ID = pt.ROW_ID 

select pt.ROW_ID 

from &Table_Owner.S_ORG_EXT tl, 
&Table_Owner.S_ORG_EXT pt 
where : pr imary_row_id = tl.ROW_ID 
and tl.PARENT_OU_ID = pt.ROW_ID 

/ 
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Sub -Statements for Position Rules 
Log Manager Visibility SQL Statements 
SQL Statonent Tonplate 

5 

exists (select 'X' 

from &Tables 

&Table_Ovni.er . S_EMP_POSTN ep , 
&Table_Owner.S_NODE_EMP ne, 
10 &Table_Ovnier.S_NODE_REL nr 

where iir.NODE_ID = :nocle_id 

and nr.SUB_NODE_ID = ne.NODE_ID 
and ne.EMP_ID = ep.EMP_ID 
cuid ep.POSITION_ID = &Join_Coluinn 
15 &Joins) 
/ 

Algorithm 

Build paths. Join path to primary table. ROW_IDl Job position column to position table. 

20 

IF position column table = primary table 
THEN 

-- can optimize: join primary_table directly to 
S_EMP_POSTN 
25 &Tables: add nothing 
&Joins : add nothing 

&Join_Coltjmn : "primary _table. <position column>" 
ELSE 

Get paths from position column table to primary table. 
30 - The paths will not include the primary table 

- The paths will not include the position colxomn 
ScTables Clause: 

- Add every table in path, last elem ent first 

" &Table_Owner . <pathcol [N] - >pTable- >pTableName> 

35 jN" 

&Joins Clause: 

- Add joins for all path cols except the last element: 

"and jN.<pathcol [N] ->pColumnName> = jN+l.ROW_ID" 

- Add join from last element to primary rowid: 

40 "and j<last>.<pathcol [last] ->pCol\amnName> = 

primary_table . ROW_ID" 

&Join_Column : " jl.<position coltimn>" 
END IF 

45 Replace &Tables, &Join_Column and SiJoins in the SQL 
statement template. 

Example 1: Opportunity Position 

50 Object: Opportunity (primary table: S_OPTY) 

Position Column: S_OPTY_POSTN . POSTN_ID 
Path Cols: S_OPTY_POSTN.OPTY_ID 
&Tables: S_OPTY_POSTN jl 

SiJoins: cmd jl.OPTY_ID = primary_table.ROW_ID 
-67- 
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&Join_Coluinn : j 1 . POSTN_ID 



(select 'X' 

from &Table_Ovmer.S_OPTY_POSTN jl, 
&Table_Owner . S_EMP_POSTN ep , 
&Tabl e_Ovmer . S_NODE_EMP ne , 
&Table_Owner.S_NODE_REL nr 
where nr.NODE_ID = :node_id 

and nr.SUB_NODE_ID = ne.NODE_ID 

and ne.EMP_ID = ep.EMP_ID 

and ep-POSITION_ID = jl.POSTN_ID 

and jl.OPTY_ID = primary_table.ROW_ID) 



IS Example 2: Quote Position 

Object: Quote (ptable: S_DOC_QUOTE) 
Position Column: S_DOC_QUOTE . POSTN_ID 
Path : S_DOC_QUOTE . ROW_ID 
20 &Tables : none 

&Joins : none 

&Join_Coliimn : primary_table . POSTN_ID 

exists (select 'X' 
25 from &:Table_Owner .S_EMP_POSTN ep, 

&Tabl e_Ovme r . S_NODE_REL nr , 
&Table_Owner.S_NODE_EMP ne 
where nr.NODE_ID = :node_id 

and nr.SUB_NODE_ID = ne.NODE_ID 
30 and ne.EMP_ID = ep.EMP_ID 

and ep.POSITION_ID = 
primary_table . POSTN_ID) 
/ 



Log Manager Related Dock Object SQL Statements 

35 

SQL Statement Templates 
Node to Current Dock Object 



select pt.ROW_ID 
40 from &Table_Owner.S_NODE_REL join_table, 

ScTable_Owner . S_NODE_EMP ne , 
&Tabl e_Owner . S_EMP_POSTN ep , 
SbTables 

where join_table.NODE_ID = :node_id 
45 and join_table .NODE_ID = :primary_row_id 

and join_tal3le.SUB_N0DE_ID = ne.NODE_ID 
and ne.EMP_ID = ep.EMP_ID 
and ep.POSITION_ID = &Join_Coluinn 
&Joins 

50 / 



Algorithm 
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Build paths. Join path to pt.ROW_IDl Join position column to position table. Alw^ join to 
primary table so the statement only leturns related objects that really exist. E.g. only retrieve 
Opportunities that really oust. 

5 IF position colvunn table = primary table 
THEN 

-- can optimize: join primary_table directly to 
S_EMP_POSTN 

&Tables: <primary table> pt 
10 SiJoins : empty 

SiJoin_Coliaiin: "pt . <position column>" 
ELSE 

Get paths from position column table to primary table. 

- The paths will not include the primary table 
15 - The paths will not include the position column 

&Tables Clause: 

- Add every table in path first element first 

"&Table_Owner.<pathcol [N] ->pTable->pTableName>" 

- Add primary table: <primary table> pt 
20 ScJoins Clause: 

- Add joins for all path cols except the last element: 

"and jN.<pathcol [N] ->pColumnName> = jN+l.ROW_ID" 

- Add join from last element to primary rowid: 

"and j<last>. <pathcol [last] ->pColumxiName> = 
25 pt.ROW_ID'' 

SkJoin_Column: " jl.<position coltunn>" 
END IF 

Replace &Tables, &Join_Column and SiJoins in the SQL 
30 statement template. 

Example 1: Opportunity Position 

Object: Opportunity (ptable: S_OPTY) 
35 Position Column: S_OPTY_P0STN. POSTN_ID 

Path : S_OPTY_POSTN . OPTy_ID 
&Tables: S_OPTy_POSTN jl, S_OPTY pt 
SJoins : and jl.OPTY_ID = pt.ROW_ID 
&Join Column:: jl.POSTN ID 

40 

select pt.ROW_ID 

from &Table_Owner .S_NODE_REL join_table, 
&Tcibl e_Owner . S_NODE_EMP ne , 
&Tabl e_Owner . S_EMP_POSTN ep , 
45 &Table_Owner.S_OPTY_POSTN jl, 

&Table_Owner . S_OPTY pt 
where join_table.NODE_ID = :node_id 

and j oin_table . NODE_ID = :primary_row_id 
and join_table.SUB_NODE_ID = ne.NODE_ID 
50 and ne.EMP_ID = ep-EMP_ID 

and ep.POSITION_ID = jl.POSTN_ID 
and jl.OPTY_ID = pt.ROW ID) 

/ 

55 
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Example 2: Quote Position 

Object: Quote (ptable: S_DOC_QUOTE) 
Position Column: S_DOC_QUOTE . POSTN_ID 
5 Path: S_D0C_QUOTE.R0W_ID 

&Tables: S_DOC_QUOTE pt 
SeJoins : none 
&Join_ColiMUi: pt.POSTN_ID 



10 select pt.ROW_ID 

from &Table_Ovmer,S_NODE_REL join_table, 
&Tabl e_Owner . S_NODE_EMP ne , 
&Table_Ovnier . S_EMP_POSTN ep, 
&Table_Ovmer.S_DOC_QUOTE pt 
15 where join_table.NODE_ID = :node_id 

and join_table.NODE_ID = : primary_row_id 
and join_table.SUB_NODE_ID = ne.NODE_ID 
and ne.EMP_ID = ep.EMP_ID 
and ep.P0SITION_ID = pt.POSTN_ID) 
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Sub-Statements for Position Manager Rules 
Ljog Manager Visibility SQL Statements 

SQL Statement Ten^late 

5 

exists 



10 



15 



/ 

20 Algorithm 

Same as Position Rule algorithm, except we use the SQL statement template above. 

Log Manager Related Dock Object SQL Statements 

SQL Statement Templates 
25 Node to Current Dock Object 

select pt.ROW_ID 

from &Table_Ovmer.S_NODE_REL join_table, 
&Tabl e_Owner . S_NODE_EMP ne , 
30 &Tat)le_Owner.S_EMP_POSTN ep, 

&Tcible_Owner.S_POSTN_RPT_REL prr 
&Tables 

where join_table.NODE_ID = :node_id 

and join_table.NODE_lD = : primary_row_id 
35 and join_table.SUB_NODE_ID = ne.NODE_ID 

and ne.EMP_ID = ep.EMP_ID 
and ep.POSITION_ID = prr . POSITION_ID 
and prr . SUB_POSTN_ID = &Join_Coluinn 
&Joins 

40 / 

• Employee to Current Dock Object 
select pt.ROW_ID 

45 iiom&Tible OwoerS NODE RELnr, 

&-ftble_Owner.S_N0DE_EMP no, 
&TMe OwnetS_EMP_POSrN ep, 
&T«blB_OwnenS_POSrN_RFr_REL prr 

50 where iir.NODE_ID <= :node id 

■od iir.SUB_NODE_ID = ^NODE_ID 
■nd ncEMPID = ep.EMPJD 
and ep.EMP_n> = T»riinaiy_TOW_td 
ind ep.POSmON_ID = prr.POSrnON_ID 
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from &Tables 

&Table_Owner . S_POSTN_RPT_REL prr , 
&Table_Ovmer . S_EMP_POSTN ep , 
&Table_Owner . S_NODE_EMP ne , 
&Table_Owner . S_NODE_REL nr 
where nr.NODE_ID = :node_id 

and nr.SUB_NODE_ID = ne.NODE_ID 
euid ne.EMP_ID = ep.EMP_ID 
and ep.POSITI0N_ID =. prr.POSITION_ID 
and prr.SUB_POSTN_ID = SbJoin_Colxiinn 
ScJoins) 
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and pir.SUB_POSrN_ID = &Joiii_Coluinn 
AJoins 



5 • Position to Current Dock Object 
select pt.ROW_ID 

from &.Table_Owner.S_NODE_llEL nr, 
&Table_Owner.S_NODE_EMP ne, 
10 &Table3ownerS_EMP_rosrN ep, 

&Tbble Owner.S_POSrN_RFr_RELjoin_«able 
&1kblJ 
where nr.NODE_ID = :node_id 
and nr.SUB_NODE_ID = ne.NODE_ID 
15 and ne.EMP_ID = ep.EMP.HJ 

and ep.POSfriON_ID = :primaiy_iTjw_id 

and join_table.POSmON_ID = :primaiy_iDw_id // help Sybase by providing value 

and join~tabl6.SUB_POSrN_lD = &Join_Column 

&Joins 

20 / 
Algorithm 

Same as Position Rule algorithm, except we create related dock objects firom Nodes, Employees, 
Positions and use the SQL statement templates above. 

25 
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Sub-Statements for Employee Rules 
Log Manager Visibility SQL Statements 

SQL Statement Template 

5 

exists (select 'X' 

from &Tables 

&Table_Owner . S_NODE_EMP ne , 
&Table_Ovnier.S_NODE_REL nr 
10 where nr.NODE_ID = :node_id 

and nr . SUB_NODE_ID = ne.NODE_ID 
and ne.EMP_ID = &Join_Colvimn 
&Joins) 

/ 

15 

Algorithm 

Same as Position Rule algorithm, except we use the SQL statement template above. 

Log Manager Related Dock Object SQL Statements 

20 SQL Statement Templates 

Node to Current Dock Object 

select pt.ROW_ID 

from &Table_Ovmer.S_NODE_REL join_table, 
25 &Table_C)vnaer . S_NODE_EMP ne 

&Tcibles 

where join_table.NODE_ID = :node_id 

euid join_tc±)le.NODE_ID = : primary_row_id 
and join_table.SUB_NODE_ID = ne.NODE_ID 
30 and ne.EMP_ID = &Join_Column 

&Joins 

/ 

Algorithm 

35 Same as Position Rule algorithm, except we use the SQL statement template above. 
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Sub -Statements for Employee Manager Rules 
Log Manager Visibility SQL Statements 

SQL Statement Template 

5 

exists (select 'X' 

from &Tables 

&Table_Owner.S_EMP_POSTN psub, 
&Tabl e_Ovnier . S_POSTN_RPT_REL prr , 
10 &Table_Owner . S_EMP_POSTN pmgr, 

&Table_Owner . S_NODE_EMP ne , 
&Table_Owner.S_NODE_REL nr 
where nr.NODE_ID = :node_id 

and nr.SUB_NODE_ID = ne.NODE_ID 
15 and ne.EMP_ID = pmgr.EMP_ID 

and pmgr.POSITION_ID = prr . POSITION_ID 
and prr . SUB_P0STN_ID = psub.POSlTION_lD 
and psub.EMP_ID = &Join_Coluinn 
& Jo ins) 

20 / 
Algorithm 

Same as Position Rule algorithm, except we use the SQL statement template above. 

Log l\aanager Related Docit Object SQL Statements 

25 

SQL Statement Templates 
Node to Current Dock Object 

select pt.ROW_ID 
30 from ScTable_Owner . S_NODE_REL join_table, 

&Table_Owner . S_NODE_EMP ne , 
ScTable_Owner . S_EMP_POSTN pmgr, 
&Table_Owner . S_POSTN_RPT_REL prr, 
&;Table_Owner . S_EMP_POSTN psub 
35 &Tables 

where join_table.NODE_ID = :node_id 

and join_table.NODE_ID = :primary_row_id 
and join_table.SUB_NODE_ID = ne.NODE_ID 
and ne.EMP_ID = pmgr.EMP_ID 
40 and pmgr.POSITION_ID = prr . POSITION_ID 

and prr.SUB_POSTN_ID = psi±).POSITION_ID 
and psub.EMP_ID = &Join_Column 
SbJoins 

/ 

45 

• Employee to Current Dock Object 
select pt.ROW_ID 

from &T«ble_Owner.S_N0DE_REL nr, 
50 &1U)le_OwnetS_NODE_EMPiie, 

&1ible"owner.S~^P_POSrN pmb, 
&1«>le_Owner.S_POSrrN_RFr_REL prr, 
&1kble_Owner.S_EMP_POSrN pmgr 
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&lU>let 
wheie iif.NODE_ID = :node_id 
tod iir.SUB_NODE_ID = ne.NODE_ID 
and ne-EMP ID = pingr.EMP_ID 
and pnigr.EMP_ID = :primfliy_rnw_id 
and pnigr.POSmON_ID = prr.POSmON_ID 
and prr.SUB_POSrN~ID = psub.POSmON_ID 
and psub.EMP_ID <= &Joui_Coluinn 



• Position to Current Dock Object 
select pt.ROW_ID 

from &Table_Owner.S_NODE_REL nr. 

&T«)le_Owner.S_NODE_EMP ne, 

&Table~Owner.S_EMP_POSrN pnib, 

&1ib!eIowner.S_POSrrN_RIT_REL join_table, 

&1U>lo_Owner.S_EMP_p6srN pmgr 

Alkblei 
where nr.NODE_ID = :node_id 
and nr.SUB_NODE_ID = ne.NODE_lD 
and ne.EMP_ID = pn«r.EMP_ID 
and pmgr.POSmON_ID ■» :primafy_rowJd 

and join_lable.POSITlON_ID = :prim«iy_iw_id // help Sybase by providing value 
andjoin_table.SUB_POSfN_ID = p8ub.POSrnON_ID 
and psub.EMP_ID = &Join_Column 

/ 

Algoritbm 

Same as Position Rule algorithm, except we create related dock objects from Nodes, Emplcyees, 
Positions and use the SQL statement templates above. 



35 
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ExaxQile 

Here are examples of visibility rules for the Account docking object and sql statements that Log 
Manager and DBXtract generate for each visibility rule. 

Visibility Rules for Organization 



» 


-We 
Type 


Partial 
Flag 


titfi tHaumtat 


Check 
Olyect 


Ckeckbock 

Oiyect Source 


(leek bock Ohiect 
Target Cofamm 








Sql 


N 


primary table.uvii'i _b'' 
LG = -V' 
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& Ailtnt W)ST 
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POSITION ID 




3 




N 










PR POSTNJD 




4 


Cbeck 
Dock 
Object 






t 


ROW_lb 


PR_DEPT_OU_n) 






5 


Cbeck 
Dock 


V 




Contac 


S OR«_EOT 
ROw_n) 


■ S PER one UNI 
T 

ou n> 






6" 


theck 
Dock 
1 Oluect 


V 






ROW_n> 


- S 6r6 tiEL 
PRTNR_OU_n) 







Rule Descriptions 

15 1. Rule 1: Account is a competitor 

2. Rule 2: Sales rep is on the account team 

3. Rule 3: Manager of the primary sales rep on the Account 

4. Rule 4: Primary Accoimt for a Contact you have visibility on 

5. Rule 5: Secondary Accotmt for a Contact you have full visibility on 
20 6. Rule 6: Account for a partner Account you have full visibility on 

6. Log Manager Visibility SQL Statements 

Log Manager nms the rule sql statements OR-cd together: 



select 'X' 

from ScTable_Ovnier.<priinary table> priinary_table 
where priinary_table .ROW_ID = <primary_row_id> // 
rule 1 

and ( (priinary_table . CMPT_FLG = 'Y') 

OR (exists (select 'X' // 

rule 2 

f rom ScTabl e_Owner . S_NODE_REL 



nr, 
ne, 
ep. 



&Table_Ovmer . S_NODE_EMP 
&Table Ovmer . S_EMP_POSTN 



StTable Ovmer . S_ACCNT_POSTN jl 

~ where nr.NODE_ID = :node_id 

40 and nr . SUB_NODE_ID = 

ne.NODE ID 

and ne.EMP_ID = ep.EMP_ID 
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and ep.POSITION_ID = 

j 1 . POSITION_ID 

and jl.OU_ID = 

primary_table . ROW_ID) 

OR (exists (select 'X' // rule 

3 

from &Table_Owner.S_NODE_REL 

nr, 

&Table_Ovraer . S_NODE_EMP 

ne, 

&Table_Ovmer . S_EMP_POSTN 



&Table_Owner . S_POSTN_RPT_REL prr 

where nr.NODE_ID = :node_id 
and nr.SUB_NODE_ID - 

ne.NODE_ID 

and ne.EMP_ID = ep.EMP_ID 
and ep.POSITION_ID - 

prr.POSITION_ID 

and prr.SUB_POSTN_ID = 
priinary_table . PR_POSTN_ID) 

OR (exists (select ' C II rule 

4 

f rom &Tabl e_Ovmer . S_DOB J_INST 

di, 

&Table_Owner-S_CONTACT tl 
where di.NODE_ID = :node_id 

and di.DOBJ_ID = <Contact Dock 

Object Id> 

and di.STAT_FLG = 'F' 
and di . PR_TBL_ROW_ID - tl.ROW_ID 
and tl.PR_DEPT_OU_ID = 
priinary_table . ROW_ID) 
OR (exists (select 'C // 
rule 5 

from &Table_Owner . S_DOBJ_INST 

di, 

&Tabl e_Owner . S_PER_ORG_UNIT t 1 
where di.NODE_ID = :node_id 

and di.DOBJ_ID = <Contact Dock 

Object Id> 

and di-STAT_FLG = 'F' 
and di . PR_TBL_ROW_ID = tl.PER_ID 
and tl.OU_ID = 
primary_table . ROW_ID) 

OR (exists (select 'C // 
rule 6 

from &Table_Owner . S_DOB J_INST 

di, 

&Table_Owner . S_ORG_REL tl 
where di.NODE_ID = :node_id 

and di.DOBJ_ID = <Account Dock 

Object Id> 

and di.STAT FLG = 'P' 
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and di . PR_TBL_ROW_ID 

tl.OU ID 

and tl.PRTNR_OU_ID = 
priinary_table . ROW_ID) 
) 

/ 



Log Manager Related Dock Object SQL Statements 
• Nodes 

10 

select pt.ROW_ID // rule 2 

from &,Table_Owner.S_NODE_RELjoin, 
&T«blo_Owner.S_NODE_EMP ne, 
&Table~Owner.S_EMP_PbsTN ep, 
15 &Table_Owner.S_ACCNT_POSTNjl, 
&T«ble~0wner.S_OR0_EXT pt 
where join_ttble.NODE_ID = :node_id 
«ndjoin uble.NODEJD = :primaiy_row_id 
aiidjoin~table.SUB_NODE_ro= ne.NODE_ID 
20 and ne.EMP_ID = ep.EMPllD 

and ep.POSrnON_ID ■= jl.POSmON_ID 
andjl.OUJD = pt.ROW_ID 

25 select pt.ROW_ID // nUe 3 

from &TBble_Ovraer.S_NODE_RELjom_uble, 
&Table_Owner.S_NODE_EMPne, 
&TabIe~Owner.S_EMP_POSTN ep, 
&Table3owner.S_P0STN_RPT_RELprr. 
30 &Table"owner.S_ORG_EXTpt 
where join_uble.NODE_ID = :node_id 
4ndjoinjiible.NODE_ID= :primaty_r(»w_id 
andjoin~table.SUB_NODE_ID= ne.NODE_ID 
and oB.^4P_ID = ep.EMP_ID 
35 and ep.POSmON_ID = prr.POSmON_lD 

and prr.SUB_POSTN_ff) = pt.PR_POSTN_ID 



select pt.ROW_ID // rule 3 

from &Table_Owner.S_NODE_REL nr. 

&Table_Owner.S_NODE_EMP ne, 

&Table~Owner.S_EMP_POSTN qi, 

&Table~Owner.S_POSTN_RFr_RELprr, 

&Table_Owner.sl0R0_BCT pt 
where nr.NODE_ID = modejd 
and nr.SUB_NODE_ID = ne.NODE_ID 
and ne.EMP_ID = ep.EMP_ID 
and ep.EMP_ID = :priniaty_row_id 
and ^.POSITION_ID = prr.POSmON_ID 
and prr.SUB POSTN_lD = pt.PR_POSTN_ID 
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select pt.ROW_ID // rule 3 

S fiom&Tible_Owner.S_NODE_RELiiT, 
&Table_Owiier.S_NODE_EMPiie, 
&T«ble Owner.S EMP POSTNep, 
&T«ble3c>wner.S_POSTN_RPT_RELjom_table, 
&T«ble_Owiier.S_ORa_BCT pt 
10 where iir.NODE_ID <=~:nodeJd 

and iir.SUB_NODE_ID = ne.NODE_ID 
and no.EMP ID = ep.EMP ID 
and ep.POSmON_ID = :primaiy_row_id 
and join table.POSmON_ID = :ptimary_row_id 
15 and joinItable.SUB_POsfN_ID = pt.PR ~POSTN_ID 



Contacts 

select pt.ROW_ID // rule 4 

ftom &T«ble_Owner.S_C0NTACTtl, 
&Tablo_Owner.S_ORO_EXT pt 
where T)rinuuy_tt)w_id = tl .ROW_ID 
and tl .PR_DEPT_OU_ID = pt.ROW_ID 



select pt.ROW ID 

ftom &Table3owner.S_PHR_ORO_UNrr tl . 
&Table_Owner.S_OR0_EXT pt 
where :ptimary_row_id = tl.PER_ID 

and tl.OU_ID = pt.ROW_ID 



Accounts 

select pt.ROW_ID // rule 6 

ftom &Table_Owner.S_ORO_REL tl , 
&Table_Owner.S_ORO_EXT pt 
where nrimaiy rowjd = tl .OU_ID 
and tl.PRTNR_OU_ID = pt.ROW_ID 
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CLAIMS 

1 . A method of managing a database, said database including a central 
database (3) and separate partially replicated databases (23a, 23b, 23c), 
said separate partially replicated databases (23a, 23b, 23c) residing at 
separate nodes (21a, 21b, 21c), each of said partially replicated databases 
(23a, 23b, 23c) having an associated visibility strength, comprising 
determining the visibility strength of a partially replicated database (23a, 
23b, 23c) to data being propagated, and propagating said data to the 
partially replicated database (23a, 23b, 23c) only if the partiaUy replicated 
database (23a, 23b, 23c) has visibility to the data. 

2. An article of manufacture comprising: 

a computer usable medium having computer readable program code 
means embodied therein for causing determining the visibility 
strength of a partially r^licated database (23a, 23b, 23c) to data 
being propagated, determining therefrom the visibility of the 
partially replicated database (23a, 23b, 23c) to the data being 
propagated, and propagating said data to a partially replicated 
database (23a, 23b, 23c) only if the partially rq)licated database 
(23a, 23b, 23c) has visibility to the data, the computer readable 
program means in said article of manufacture comprising: 

computer readable program code means for causing a 
computer to effect determining the visibility strength 
of a partially rq)licated database (23a, 23b, 23c) to 
data being propagated; 

computer readable program code means for causing a 
computer to effect propagating said data to a partially 
replicated database (23a, 23b, 23c) only if the 
partially replicated database (23a, 23b, 23c) has 
visibility to the data. 
3. A program storage device readable by a machine, tangibly 

embodying a program of instructions executable by a machine to 
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perform method steps for managing a database, said method steps 
comprising determining the visibility strength of a partially 
rqjlicated database (23a, 23b, 23c) to data being propagated, 
determining therefrom the visibility of the partially replicated 
5 database (23a, 23b, 23c) to the data being propagated, and 

propagating said data to a partially replicated database (23a, 23b, 
23c) only if the partially replicated database (23a, 23b, 23c) has 
visibility to the data. 
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